Closed Bug 714344 Opened 14 years ago Closed 14 years ago

Intermittent Assertion failure: !noAvailableArenas() (during browser_bug687573_vscroll.js ?) or Talos dromaeo crash [@ js::gc::Chunk::allocateArena]

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla12

People

(Reporter: benjamin, Assigned: igor)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

I experienced a test failure which philor says isn't currently filed: https://tbpl.mozilla.org/php/getParsedLog.php?id=8237304&tree=Mozilla-Inbound&full=1 Assertion failure: !noAvailableArenas(), at /builds/slave/m-in-osx64-dbg/build/js/src/jsgc.cpp:715 WARNING: shutting down early because of crash!: file /builds/slave/m-in-osx64-dbg/build/dom/plugins/ipc/PluginModuleChild.cpp, line 746 WARNING: plugin process _exit()ing: file /builds/slave/m-in-osx64-dbg/build/dom/plugins/ipc/PluginModuleChild.cpp, line 711 TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/devtools/sourceeditor/test/browser_bug687573_vscroll.js | Exited with code 1 during test run INFO | automation.py | Application ran for: 0:17:00.920710 INFO | automation.py | Reading PID log: /var/folders/Hs/HsDn6a9SG8idoIya6p9mtE+++TI/-Tmp-/tmp7ahdUBpidlog PROCESS-CRASH | chrome://mochitests/content/browser/browser/devtools/sourceeditor/test/browser_bug687573_vscroll.js | application crashed (minidump found) Crash dump filename: /var/folders/Hs/HsDn6a9SG8idoIya6p9mtE+++TI/-Tmp-/tmpx_2cic/minidumps/43BD9592-B848-442F-B958-CF0BD3A0AFF3.dmp Operating system: Mac OS X 10.6.8 10K549 CPU: amd64 family 6 model 23 stepping 10 2 CPUs Crash reason: EXC_BAD_ACCESS / KERN_INVALID_ADDRESS Crash address: 0x0 Thread 0 (crashed) 0 XUL!CrashInJS [jsutil.cpp:aa47e51cbd8a : 95 + 0x0] 1 XUL!js::gc::Chunk::allocateArena [jsgc.cpp:aa47e51cbd8a : 715 + 0x17] 2 XUL!js::gc::ArenaLists::allocateFromArena [jsgc.cpp:aa47e51cbd8a : 1494 + 0xd] 3 XUL!js::gc::ArenaLists::refillFreeList [jsgc.cpp:aa47e51cbd8a : 1706 + 0xe] 4 XUL!JSObject::create [jsgcinlines.h:aa47e51cbd8a : 397 + 0xb] 5 XUL!js::NewObjectWithClassProto [jsobj.cpp:aa47e51cbd8a : 2926 + 0x15] 6 XUL!js_NewFunction [jsfun.cpp:aa47e51cbd8a : 2159 + 0x18] 7 XUL!js_DefineFunction [jsfun.cpp:aa47e51cbd8a : 2334 + 0x24] 8 XUL!JS_DefineFunctions [jsapi.cpp:aa47e51cbd8a : 4578 + 0x21] 9 XUL!js::GlobalObject::initFunctionAndObjectClasses [GlobalObject.cpp:aa47e51cbd8a : 428 + 0xa] 10 XUL!js_InitObjectClass [GlobalObject.h:aa47e51cbd8a : 219 + 0xa] 11 XUL!JS_ResolveStandardClass [jsapi.cpp:aa47e51cbd8a : 1931 + 0x9] 12 XUL!nsWindowSH::NewResolve [nsDOMClassInfo.cpp:aa47e51cbd8a : 6620 + 0x15] 13 XUL!XPC_WN_Helper_NewResolve [XPCWrappedNativeJSOps.cpp:aa47e51cbd8a : 1123 + 0x2a] 14 XUL!LookupPropertyWithFlagsInline [jsobj.cpp:aa47e51cbd8a : 5532 + 0x13] 15 XUL!js_GetPropertyHelperInline [jsobj.cpp:aa47e51cbd8a : 5954 + 0x1c] 16 XUL!JS_ForwardGetPropertyTo [jsobjinlines.h:aa47e51cbd8a : 211 + 0x15] 17 XUL!XPCWrappedNativeScope::SetGlobal [XPCWrappedNativeScope.cpp:aa47e51cbd8a : 269 + 0x18] 18 XUL!nsXPConnect::InitClassesWithNewWrappedGlobal [nsXPConnect.cpp:aa47e51cbd8a : 1332 + 0x11] 19 XUL!nsJSContext::CreateNativeGlobalForInner [nsJSEnvironment.cpp:aa47e51cbd8a : 2242 + 0x2c] 20 XUL!nsGlobalWindow::SetNewDocument [nsGlobalWindow.cpp:aa47e51cbd8a : 2027 + 0x2b]
https://tbpl.mozilla.org/php/getParsedLog.php?id=8246079&tree=Mozilla-Inbound Rev3 Fedora 12 mozilla-inbound pgo talos dromaeo on 2011-12-30 18:52:56 PST for push a258a0b2d9e4 NOISE: Cycle 1: loaded http://localhost/page_load_test/dromaeo/cssquery-dojo.html (next: http://localhost/page_load_test/dromaeo/cssquery-ext.html) NOISE: Cycle 1: loaded http://localhost/page_load_test/dromaeo/cssquery-ext.html (next: http://localhost/page_load_test/dromaeo/cssquery-jquery.html) NOISE: Cycle 1: loaded http://localhost/page_load_test/dromaeo/cssquery-jquery.html (next: http://localhost/page_load_test/dromaeo/cssquery-mootools.html) NOISE: Cycle 1: loaded http://localhost/page_load_test/dromaeo/cssquery-mootools.html (next: http://localhost/page_load_test/dromaeo/cssquery-prototype.html) NOISE: NOISE: __FAILbrowser non-zero return code (256)__FAIL NOISE: Cycle 1: loaded http://localhost/page_load_test/dromaeo/cssquery-dojo.html (next: http://localhost/page_load_test/dromaeo/cssquery-ext.html) NOISE: Cycle 1: loaded http://localhost/page_load_test/dromaeo/cssquery-ext.html (next: http://localhost/page_load_test/dromaeo/cssquery-jquery.html) NOISE: Cycle 1: loaded http://localhost/page_load_test/dromaeo/cssquery-jquery.html (next: http://localhost/page_load_test/dromaeo/cssquery-mootools.html) NOISE: Cycle 1: loaded http://localhost/page_load_test/dromaeo/cssquery-mootools.html (next: http://localhost/page_load_test/dromaeo/cssquery-prototype.html) NOISE: NOISE: __FAILbrowser non-zero return code (256)__FAIL NOISE: Found crashdump: /tmp/tmp_HSB9C/profile/minidumps/03272d04-e248-66f6-1bb4a181-242415f4.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: 0xc47fffc0 Thread 0 (crashed) 0 libxul.so!js::gc::Chunk::allocateArena [BitArray.h:a258a0b2d9e4 : 78 + 0x2] eip = 0x02162527 esp = 0xbf9a4bf0 ebp = 0xb3501000 ebx = 0x026ab8c0 esi = 0xa4700000 edi = 0xad1f6000 eax = 0xa46ff000 ecx = 0x0803ffef edx = 0x7fffffff efl = 0x00210297 Found by: given as instruction pointer in context 1 libxul.so!js::gc::ArenaLists::refillFreeList [jsgc.cpp:a258a0b2d9e4 : 1494 + 0xf] eip = 0x02163628 esp = 0xbf9a4c40 ebp = 0x0000001a ebx = 0x026ab8c0 esi = 0xad1f6000 edi = 0x00000006 Found by: call frame info 2 libxul.so!js::CallObject::create [jsgcinlines.h:a258a0b2d9e4 : 397 + 0xf] eip = 0x02223a0d esp = 0xbf9a4cb0 ebp = 0x00000000 ebx = 0x026ab8c0 esi = 0xa6e48808 edi = 0xaf264740 Found by: call frame info 3 libxul.so!js::CreateFunCallObject [jsfun.cpp:a258a0b2d9e4 : 677 + 0x1d] eip = 0x0215a971 esp = 0xbf9a4d20 ebp = 0xa6ed84c0 ebx = 0x026ab8c0 esi = 0xb1cfe2e8 edi = 0xb1a4a0d0 Found by: call frame info 4 libxul.so!js::mjit::stubs::FunctionFramePrologue [Stack-inl.h:a258a0b2d9e4 : 430 + 0xb] eip = 0x0232da6b esp = 0xbf9a4da0 ebp = 0xaf264740 ebx = 0x026ab8c0 esi = 0xb1cfe2e8 edi = 0xbf9a4dd0 Found by: call frame info 5 0x280dd78 eip = 0x0280dd79 esp = 0xbf9a4dd0 ebp = 0xbf9a4e08 ebx = 0xa6eb3460 esi = 0x0280dfb3 edi = 0xa6ed84c0 Found by: call frame info 6 libxul.so + 0x17348bf eip = 0x026ab8c0 esp = 0xbf9a4e10 ebp = 0xb1cfe070 Found by: previous frame's frame pointer 7 libxul.so!js::mjit::JaegerShot [MethodJIT.cpp:a258a0b2d9e4 : 1051 + 0x17] eip = 0x02275fa0 esp = 0xbf9a4e20 ebp = 0xb1cfe070 Found by: stack scanning 8 libxul.so!js::RunScript [jsinterp.cpp:a258a0b2d9e4 : 477 + 0xf] eip = 0x02195a18 esp = 0xbf9a4e80 ebp = 0xb1cfe070 ebx = 0x026ab8c0 esi = 0xaf264740 edi = 0xa6e45790 Found by: call frame info 9 libxul.so!js::InvokeKernel [jsinterp.cpp:a258a0b2d9e4 : 543 + 0x8] eip = 0x02196509 esp = 0xbf9a4ec0 ebp = 0xaf264740 ebx = 0x026ab8c0 esi = 0x9f2d4a60 edi = 0xb1cfe070 Found by: call frame info
Severity: normal → critical
OS: Windows 7 → All
Hardware: x86_64 → All
Summary: Intermittent Assertion failure: !noAvailableArenas() (during browser_bug687573_vscroll.js ?) → Intermittent Assertion failure: !noAvailableArenas() (during browser_bug687573_vscroll.js ?) or Talos dromaeo crash [@ js::gc::Chunk::allocateArena]
Whiteboard: [orange]
Version: unspecified → Trunk
This is likely to be a regression fro bug 713916 or bug 702251.
https://tbpl.mozilla.org/php/getParsedLog.php?id=8248987&tree=Mozilla-Inbound Assertion failure: !noAvailableArenas(), at e:/builds/moz2_slave/m-in-w32-dbg/build/js/src/jsgc.cpp:715 TEST-UNEXPECTED-FAIL | /tests/editor/libeditor/html/tests/browserscope/test_richtext2.html
(In reply to Bill McCloskey (:billm) from comment #2) > This is likely to be a regression fro bug 713916 or bug 702251. This is a regression from the bug 702251 indeed. If there is a just one free arena in the chunk and it is committed, then during the decommit outside the GC lock the allocation thread see the chunk as having no arenas yet it present on the available list.
Assignee: general → igor
Blocks: 702251
Attached patch v1Splinter Review
Initially for the chunk with single free arena I considered to remove it from the available list while that arena is being decommitted to preserve the available list invariant before releasing the lock. But it required to consider a few cases like were to add that chunk back. That quickly lead to rather fragile code. To avoid the extra complexity the patch just keeps the lock in that corner case. I presume that case is rare. For symmetry with AutoLock I have added the explicit AutoUnlock::unlock method rather than using the Maybe class as Maybe for some reasons is particularly prone to generate aliasing and uninitilized warnings with CC when used with wrappers around GC_LOCK. Also I changes Chunk::noAvailableArenas into hasAvailableArenas to avoid double-negation like if (!noAvailableArenas()).
Attachment #585148 - Flags: review?(wmccloskey)
Comment on attachment 585148 [details] [diff] [review] v1 Review of attachment 585148 [details] [diff] [review]: ----------------------------------------------------------------- Good catch. Thanks. ::: js/src/jsgc.cpp @@ +2276,1 @@ > ok = DecommitMemory(aheader->getArena(), ArenaSize); I don't really like the change to AutoUnlockGC. It seems like it would be easy to omit the runtime parameter and think that you have the lock when you don't. Is there a reason why you didn't use Maybe<AutoUnlockGC> here? And if that's somehow not applicable, there's an even simpler solution: if (chunk->hasAvailableArenas()) { AutoUnlockGC unlock(rt); ok = DecommitMemory(aheader->getArena(), ArenaSize); } else { ok = DecommitMemory(aheader->getArena(), ArenaSize); } Either way, I'd like to leave the AutoUnlockGC class alone.
Attachment #585148 - Flags: review?(wmccloskey) → review+
(In reply to Bill McCloskey (:billm) from comment #7) > I don't really like the change to AutoUnlockGC. It seems like it would be > easy to omit the runtime parameter and think that you have the lock when you > don't. Is there a reason why you didn't use Maybe<AutoUnlockGC> here? I had rather bad experience with Maybe<AutoLockGC> as that caused spurious warnings after seemingly unrelated changed in the code. At some point I gave up and just added an explicit lock method to AutoLock. But OK, I will use Maybe with the AutoUnlockGC. Maybe GCC will be happier this time.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla12
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: