Closed Bug 618529 Opened 14 years ago Closed 12 years ago

Intermittent "Assertion failure: m_freePtr <= m_end" in /tests/dom/src/threads/test/test_suspend.html

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: philor, Unassigned)

References

Details

(Keywords: intermittent-failure)

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1292047157.1292047731.4224.gz
Rev3 Fedora 12x64 mozilla-central debug test mochitests-2/5 on 2010/12/10 21:59:17
s: talos-r3-fed64-045

2765 INFO TEST-START | /tests/dom/src/threads/test/test_suspend.html
++DOMWINDOW == 17 (0x227c518) [serial = 1265] [outer = 0x3483ec0]
Assertion failure: m_freePtr <= m_end, at /builds/slave/mozilla-central-linux64-debug/build/js/src/assembler/jit/ExecutableAllocator.h:145
NEXT ERROR TEST-UNEXPECTED-FAIL | /tests/dom/src/threads/test/test_suspend.html | Exited with code 1 during test run
INFO | automation.py | Application ran for: 0:07:11.977077
INFO | automation.py | Reading PID log: /tmp/tmpfSJNwapidlog
PROCESS-CRASH | /tests/dom/src/threads/test/test_suspend.html | application crashed (minidump found)
Operating system: Linux
                  0.0.0 Linux 2.6.31.5-127.fc12.x86_64 #1 SMP Sat Nov 7 21:11:14 EST 2009 x86_64
CPU: amd64
     family 6 model 23 stepping 10
     2 CPUs

Crash reason:  SIGABRT
Crash address: 0x1f400000804

Thread 0 (crashed)
 0  libpthread-2.11.so + 0xee6b
    rbx = 0x00000000   r12 = 0x943ec218   r13 = 0x03481160   r14 = 0x05aed5e0
    r15 = 0x00000000   rip = 0xd360ee6b   rsp = 0xa81cfa88   rbp = 0xa81cfab0
    Found by: given as instruction pointer in context
 1  libxul.so!JS_Assert [jsutil.cpp:7aedd1d023d0 : 83 + 0x9]
    rip = 0xa1988fc9   rsp = 0xa81cfa90
    Found by: stack scanning
 2  libxul.so!JSC::ExecutablePool::alloc [ExecutableAllocator.h:7aedd1d023d0 : 145 + 0x2c]
    rip = 0xa1a4a7ce   rsp = 0xa81cfac0
    Found by: stack scanning
 3  libxul.so!JSC::AssemblerBuffer::executableCopy [AssemblerBuffer.h:7aedd1d023d0 : 148 + 0x15]
    rip = 0xa1a69b35   rsp = 0xa81cfb00
    Found by: stack scanning
 4  libnspr4.so!PR_AtomicIncrement [pratom.c:7aedd1d023d0 : 306 + 0x8]
    rip = 0x9ee61823   rsp = 0xa81cfb30
    Found by: stack scanning
 5  libxul.so!JSC::X86Assembler::X86InstructionFormatter::executableCopy [X86Assembler.h:7aedd1d023d0 : 2561 + 0xc]
    rip = 0xa1a69ba9   rsp = 0xa81cfb40
    Found by: stack scanning
 6  libxul.so!JSC::X86Assembler::executableCopy [X86Assembler.h:7aedd1d023d0 : 2233 + 0x10]
    rip = 0xa1a69bcd   rsp = 0xa81cfb60
    Found by: stack scanning
 7  libxul.so!JSC::LinkBuffer::executableCopy [LinkBuffer.h:7aedd1d023d0 : 202 + 0xc]
    rip = 0xa1a69bf9   rsp = 0xa81cfb90
    Found by: stack scanning
 8  libxul.so!JSC::LinkBuffer::LinkBuffer [LinkBuffer.h:7aedd1d023d0 : 73 + 0x1b]
    rip = 0xa1a7da68   rsp = 0xa81cfbc0
    Found by: stack scanning
 9  libxul.so!JSC::Yarr::RegexGenerator::compile [RegexJIT.cpp:7aedd1d023d0 : 1537 + 0x10]
    rip = 0xa1a8a671   rsp = 0xa81cfbf0
    Found by: stack scanning
10  libxul.so!JSC::AbstractMacroAssembler<JSC::X86Assembler>::AbstractMacroAssembler [AbstractMacroAssembler.h:7aedd1d023d0 : 46 + 0x8]
    rip = 0xa1a3c2eb   rsp = 0xa81cfc00
    Found by: stack scanning
11  libxul.so!JSC::MacroAssemblerX86Common::MacroAssemblerX86Common [MacroAssemblerX86Common.h:7aedd1d023d0 : 49 + 0x8]
    rip = 0xa1a3c303   rsp = 0xa81cfc18
    Found by: stack scanning
12  libxul.so!js::Vector<JSC::Yarr::RegexGenerator::AlternativeBacktrackRecord, 0ul, js::SystemAllocPolicy>::Vector [jsvector.h:7aedd1d023d0 : 403 + 0xc]
    rip = 0xa1a821cb   rsp = 0xa81cfc48
    Found by: stack scanning
13  libxul.so!JSC::Yarr::RegexGenerator::RegexGenerator [RegexJIT.cpp:7aedd1d023d0 : 1505 + 0x39]
    rip = 0xa1a82242   rsp = 0xa81cfc60
    Found by: stack scanning
14  libxul.so!JSC::Yarr::jitCompileRegex [RegexJIT.cpp:7aedd1d023d0 : 1573 + 0x19]
    rip = 0xa1a81b52   rsp = 0xa81cfca0
    Found by: stack scanning
Hmm, so I wonder if this is caused by the YARR allocator race in
bug 587288.  The stack looks plausible and the assertion failure
is to do with the right members.
Possibly related to bug 649289 ?
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.