Last Comment Bug 784154 - SMIL crashes on mozilla-inbound TBPL
: SMIL crashes on mozilla-inbound TBPL
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: All Linux
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-20 14:03 PDT by Daniel Holbert [:dholbert]
Modified: 2012-08-20 16:14 PDT (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Daniel Holbert [:dholbert] 2012-08-20 14:03:19 PDT
philor alerted me to some crashes in SMIL code on mozilla-inbound TPBL today.  So far, we haven't found any obviously-guilty pushes.

Filing this bug to investigate / discuss / resolve.

Sample log:
 https://tbpl.mozilla.org/php/getParsedLog.php?id=14535953&tree=Mozilla-Inbound

129074 INFO TEST-START | /tests/content/smil/test/test_smilAccessKey.xhtml
129075 INFO TEST-PASS | /tests/content/smil/test/test_smilAccessKey.xhtml | Expected animations to be paused
TEST-UNEXPECTED-FAIL | /tests/content/smil/test/test_smilAccessKey.xhtml | Exited with code 1 during test run
...
PROCESS-CRASH | /tests/content/smil/test/test_smilAccessKey.xhtml | application crashed (minidump found)
Crash dump filename: /tmp/tmph0MvXi/minidumps/62469c92-7a48-f273-502341c8-67ca0f23.dmp
Operating system: Linux
                  0.0.0 Linux 2.6.31.5-127.fc12.i686.PAE #1 SMP Sat Nov 7 21:25:57 EST 2009 i686
CPU: x86
     GenuineIntel family 6 model 23 stepping 10
     2 CPUs

Crash reason:  SIGSEGV
Crash address: 0x5cb00000

Thread 0 (crashed)
 0  firefox-bin!arena_dalloc [jemalloc.c : 4626 + 0x0]
    eip = 0x08055488   esp = 0xbf8eaec0   ebp = 0xbf8eaef8   ebx = 0x001e6118
    esi = 0x019bfb95   edi = 0x00000000   eax = 0x5cb00000   ecx = 0xbf8eafbf
    edx = 0x0007c381   efl = 0x00210206
    Found by: given as instruction pointer in context
 1  libmozalloc.so!moz_free [mozalloc.cpp : 51 + 0x7]
    eip = 0x001e5b25   esp = 0xbf8eaf00   ebp = 0xbf8eaf18   ebx = 0x001e6118
    esi = 0x019bfb95   edi = 0x00000000
    Found by: call frame info
 2  libxul.so!NS_Free_P [nsMemoryImpl.cpp : 175 + 0x7]
    eip = 0x01ddfcfc   esp = 0xbf8eaf20   ebp = 0xbf8eaf38   ebx = 0x027e584c
    esi = 0x019bfb95   edi = 0x00000000
    Found by: call frame info
 3  libxul.so!ReleaseData [nsMemory.h : 42 + 0x8]
    eip = 0x01dede40   esp = 0xbf8eaf40   ebp = 0xbf8eaf58   ebx = 0x027e584c
    esi = 0x019bfb95   edi = 0x00000000
    Found by: call frame info
 4  libxul.so!nsAString_internal::SetCapacity [nsTSubstring.cpp : 544 + 0xb]
    eip = 0x01dee386   esp = 0xbf8eaf60   ebp = 0xbf8eafa8   ebx = 0x027e584c
    esi = 0x019bfb95   edi = 0x00000000
    Found by: call frame info
 5  libxul.so!nsAString_internal::SetCapacity [nsTSubstring.cpp : 532 + 0x7]
    eip = 0x01dee434   esp = 0xbf8eafb0   ebp = 0xbf8eafc8   ebx = 0x027e584c
    esi = 0x00000000   edi = 0x019bfb95
    Found by: call frame info
 6  libxul.so!nsAString_internal::SetLength [nsTSubstring.cpp : 582 + 0x4]
    eip = 0x01dee8e2   esp = 0xbf8eafd0   ebp = 0xbf8eafd8   ebx = 0x027e584c
    esi = 0x00000000   edi = 0x019bfb95
    Found by: call frame info
 7  libxul.so!nsDocument::GetXMLDeclaration [nsTSubstring.h : 495 + 0x19]
    eip = 0x015723c0   esp = 0xbf8eafe0   ebp = 0xbf8eb008   ebx = 0x027e584c
    esi = 0x8d2f4c00   edi = 0x019bfb95
    Found by: call frame info
 8  libxul.so!nsSMILTimeValueSpec::RegisterEventListener [nsSMILTimeValueSpec.cpp : 327 + 0xb]
    eip = 0x019bfbc2   esp = 0xbf8eb010   ebp = 0xbf8eb048   ebx = 0x027e584c
    esi = 0x994d9240   edi = 0x8fdee4c0
    Found by: call frame info

This stack is bizarre, because nsSMILTimeValueSpec::RegisterEventListener never calls GetXMLDeclaration.  In fact, GetXMLDeclaration is only called in one place (according to MXR), and that's in nsXMLContentSerializer::AppendDocumentStart, which we're nowhere near.

We're also hitting crashes in the SMIL crashtest "670313-1.svg":
https://tbpl.mozilla.org/php/getParsedLog.php?id=14535994&tree=Mozilla-Inbound
REFTEST TEST-START | file:///home/cltbld/talos-slave/test/build/reftest/tests/content/smil/crashtests/670313-1.svg | 235 / 2107 (11%)
TEST-UNEXPECTED-FAIL | file:///home/cltbld/talos-slave/test/build/reftest/tests/content/smil/crashtests/670313-1.svg | Exited with code 1 during test run

...and also in the SMIL reftest "event-begin-1.svg":
https://tbpl.mozilla.org/php/getParsedLog.php?id=14535139&tree=Mozilla-Inbound
REFTEST TEST-START | file:///home/cltbld/talos-slave/test/build/reftest/tests/layout/reftests/svg/smil/event/event-begin-1.svg | 6522 / 8136 (80%)
TEST-UNEXPECTED-FAIL | file:///home/cltbld/talos-slave/test/build/reftest/tests/layout/reftests/svg/smil/event/event-begin-1.svg | Exited with code 1 during test run
Comment 1 Daniel Holbert [:dholbert] 2012-08-20 14:07:19 PDT
(In reply to Daniel Holbert [:dholbert] from comment #0)
> We're also hitting crashes in the SMIL crashtest "670313-1.svg":
> https://tbpl.mozilla.org/php/getParsedLog.php?id=14535994&tree=Mozilla-Inbound

er, that URL seems to be broken - I mighta somehow messed it up.  In any case, here's another one with a failure in the same test:
https://tbpl.mozilla.org/php/getParsedLog.php?id=14534212&tree=Mozilla-Inbound

Note that this crash's stack also involves a call from nsSMILTimeValueSpec::RegisterEventListener() to nsDocument::GetXMLDeclaration(), which is bizarre, as noted in comment 0, because there's no calls like that in the code AFAICT.
Comment 2 Daniel Holbert [:dholbert] 2012-08-20 14:13:48 PDT
Currently, the first instances of this on TBPL are on this push:
  https://tbpl.mozilla.org/?tree=Mozilla-Inbound&4e01ed5b3b80
which is a clearly-innocent tweak to mobile.js.

However, the push before that one didn't get any instances of these tests yet (at least, no Linux Mochitest-1 run, which seems to be the most common instance of this failure, for test_smilAccessKey.xhtml).  That push is:
  https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=f2b98e6e2f9c
...and that was a multi-part iframe-sandboxing push.

It's feasible that iframe-sandboxing tweaks could be involved in this bustage (particularly for mochitests, which run in an iframe).

So at this point, I'm "blaming" that push (not that its code is necessarily broken, but it at least seems to be what triggered these failures to start happening).
Comment 3 Daniel Holbert [:dholbert] 2012-08-20 14:30:22 PDT
I can't reproduce this locally with a debug mozilla-inbound build, FWIW. (running targeted mochitests in content/smil and targeted crashtests in content/smil).
Comment 4 Daniel Holbert [:dholbert] 2012-08-20 14:56:30 PDT
philor suggests that we might just need a clobber. Hopefully that fixes it...
Comment 5 Daniel Holbert [:dholbert] 2012-08-20 16:14:39 PDT
Yup, this seems to have been FIXED by philor's clobber-triggering in https://hg.mozilla.org/integration/mozilla-inbound/rev/70d0984bf533

(At least, that push has multiple completed green runs on Linux for M-1, Crashtest, & Reftest, all of which were previously running up against crashes as noted above.)

Closing this out.

Note You need to log in before you can comment on or make changes to this bug.