Closed Bug 759194 Opened 12 years ago Closed 9 years ago

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

Categories

(Core :: Audio/Video, defect)

Product:
Core
Component:
Audio/Video
Version:
13 Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: MatsPalmgren_bugz, Unassigned)

References

Details

(Keywords: crash) 

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
...
Filed an IT request to get the minidump file, bug 759197
Depends on: 759197
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.
Component: Layout → Video/Audio
QA Contact: layout → video.audio
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.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.