759194 - layout/base/crashtests/579655.html | Exited with code 1 during test run

Status: RESOLVED INCOMPLETE

(Core :: Audio/Video, defect)

Description

[Mats Palmgren (inactive)]

Rev3 Fedora 12 mozilla-beta pgo test crashtest on 2012-05-28 13:33:58 PDT for push 4bcb034bb873

TEST-UNEXPECTED-FAIL | file:///home/cltbld/talos-slave/test/build/reftest/tests/layout/base/crashtests/579655.html | Exited with code 1 during test run

Unfortunately there's no symbols for the stack trace:

Downloading symbols from: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-beta-linux/1338233604/firefox-13.0.en-US.linux-i686.crashreporter-symbols.zip
PROCESS-CRASH | file:///home/cltbld/talos-slave/test/build/reftest/tests/layout/base/crashtests/579655.html | application crashed (minidump found)
Crash dump filename: /tmp/tmpr5OXWI/minidumps/4b07127c-f0eb-02c3-24912519-5e9998fb.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: 0x4

Thread 0 (crashed)
 0  libxul.so + 0x57b613
    eip = 0x01565613   esp = 0xbfb13060   ebp = 0xada40988   ebx = 0x027220dc
    esi = 0x00000000   edi = 0xada40988   eax = 0x00000000   ecx = 0xada40988
    edx = 0x00000000   efl = 0x00010286
    Found by: given as instruction pointer in context
 1  libxul.so + 0x408ef3
    eip = 0x013f2ef4   esp = 0xbfb13070   ebp = 0xada40988
    Found by: stack scanning
 2  libxul.so + 0x57b605
    eip = 0x01565606   esp = 0xbfb13078   ebp = 0xada40988
    Found by: stack scanning
...

Comment 1

[Mats Palmgren (inactive)]

Filed an IT request to get the minidump file, bug 759197

Comment 2

[Mats Palmgren (inactive)]

I forgot to include the link to the log:
https://tbpl.mozilla.org/php/getParsedLog.php?id=12140401&tree=Mozilla-Beta

Comment 3

[Mats Palmgren (inactive)]

Thread 17 looks suspicious.  It has 1024 (reported) stack frames going through
a cycle of PR_EnterMonitor/PR_ExitMonitor every 30 frames or so, with a lot
of pulse-shm-* stack frames sprinkled throughout.

Comment 4

[Matthew Gregan [:kinetik]]

I think the pulse-shm-* entries in the stack are just the tracer getting confused, PulseAudio never executes code inside the shared memory it allocates (it never maps that memory with PROT_EXEC).  Without a decent stacktrace and with the dump no longer available according to bug 759197 there's not much hope of fixing this.