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)
Core
JavaScript Engine
Tracking
()
RESOLVED
FIXED
mozilla12
People
(Reporter: benjamin, Assigned: igor)
References
Details
(Keywords: intermittent-failure)
Attachments
(1 file)
4.63 KB,
patch
|
billm
:
review+
|
Details | Diff | Splinter Review |
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]
Comment 1•14 years ago
|
||
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.
Comment 3•14 years ago
|
||
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
Assignee | ||
Comment 4•14 years ago
|
||
(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 | ||
Comment 5•14 years ago
|
||
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 6•14 years ago
|
||
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+
Assignee | ||
Comment 8•14 years ago
|
||
(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.
Assignee | ||
Comment 9•14 years ago
|
||
Comment 10•14 years ago
|
||
So far, so good.
https://hg.mozilla.org/mozilla-central/rev/29f66fc7e017
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla12
Updated•13 years ago
|
Keywords: intermittent-failure
Updated•13 years ago
|
Whiteboard: [orange]
You need to log in
before you can comment on or make changes to this bug.
Description
•