Closed Bug 988821 Opened 12 years ago Closed 12 years ago

Generational GC causes gcNursery.isEmpty() assertion failures on MacOSX

Categories

(Core :: JavaScript: GC, defect)

Product:
Core
Component:
JavaScript: GC
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla31

People

(Reporter: jonco, Assigned: jonco)

References

Details

Attachments

(1 file)

bug988821-nurseryIsEmptyAssertion
5.78 KB, patch
terrence
: review+
Details | Diff | Splinter Review
Generational GC was backed out for causing frequent failures of the following form on MacOS: 01:38:38 INFO - Assertion failure: zone->runtimeFromAnyThread()->gcNursery.isEmpty(), at /builds/slave/m-in-osx64-d-00000000000000000/build/js/src/jsgcinlines.h:248 01:38:41 INFO - TEST-INFO | Main app process: killed by SIGHUP 01:38:41 WARNING - TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/docshell/test/chrome/test_bug662200.xul | application terminated with exit code 1 01:38:41 INFO - INFO | runtests.py | Application ran for: 0:03:06.022642 01:38:41 INFO - INFO | zombiecheck | Reading PID log: /var/folders/lr/nwz2bgs53v1_nr5s75sk7lqh00000w/T/tmpe7ASjUpidlog 01:38:55 WARNING - PROCESS-CRASH | chrome://mochitests/content/chrome/docshell/test/chrome/test_bug662200.xul | application crashed [@ js::gc::CellIterUnderGC::CellIterUnderGC(JS::Zone*, js::gc::AllocKind)] 01:38:55 INFO - Crash dump filename: /var/folders/lr/nwz2bgs53v1_nr5s75sk7lqh00000w/T/tmpwfy5Hl/minidumps/A3FAE7A5-8E0F-494C-A94B-96C8C939D4F3.dmp 01:38:55 INFO - Operating system: Mac OS X 01:38:55 INFO - 10.8.0 12A269 01:38:55 INFO - CPU: amd64 01:38:55 INFO - family 6 model 42 stepping 7 01:38:55 INFO - 8 CPUs 01:38:55 INFO - Crash reason: EXC_BAD_ACCESS / KERN_INVALID_ADDRESS 01:38:55 INFO - Crash address: 0x0 01:38:55 INFO - Thread 0 (crashed) 01:38:55 INFO - 0 XUL!js::gc::CellIterUnderGC::CellIterUnderGC(JS::Zone*, js::gc::AllocKind) [jsgcinlines.h:3f8e27e02893 : 248 + 0x0] 01:38:55 INFO - rbx = 0x00007fff78469c68 r12 = 0x00007fff5fbf7d38 01:38:55 INFO - r13 = 0x00000001091a6698 r14 = 0x000000010c808000 01:38:55 INFO - r15 = 0x0000000000000014 rip = 0x0000000103e646d0 01:38:55 INFO - rsp = 0x00007fff5fbf7ab0 rbp = 0x00007fff5fbf7ad0 01:38:55 INFO - Found by: given as instruction pointer in context 01:38:55 INFO - 1 XUL!js::jit::JitRuntime::Mark(JSTracer*) [jsgcinlines.h:3f8e27e02893 : 252 + 0x4] 01:38:55 INFO - rbx = 0x00000001091a6698 r12 = 0x00007fff5fbf7d38 01:38:55 INFO - r13 = 0x00000001091a6698 r14 = 0x00000001091a6200 01:38:55 INFO - r15 = 0x0000000000000000 rip = 0x0000000103f28bc7 01:38:55 INFO - rsp = 0x00007fff5fbf7ae0 rbp = 0x00007fff5fbf7b50 01:38:55 INFO - Found by: call frame info 01:38:55 INFO - 2 XUL!js::gc::MarkRuntime(JSTracer*, bool) [RootMarking.cpp:3f8e27e02893 : 741 + 0x7] 01:38:55 INFO - rbx = 0x000000010c808000 r12 = 0x00007fff5fbf7d38 01:38:55 INFO - r13 = 0x00000001091a6698 r14 = 0x00000001091a6200 01:38:55 INFO - r15 = 0x0000000000000000 rip = 0x0000000103dfd442 01:38:55 INFO - rsp = 0x00007fff5fbf7b60 rbp = 0x00007fff5fbf7c40 01:38:55 INFO - Found by: call frame info 01:38:55 INFO - 3 XUL!IncrementalCollectSlice [jsgc.cpp:3f8e27e02893 : 3165 + 0x9] 01:38:55 INFO - rbx = 0x00000001091a6200 r12 = 0x00007fff5fbf7d38 01:38:55 INFO - r13 = 0x00000001091a67b0 r14 = 0x00000001091a6200 01:38:55 INFO - r15 = 0x00000001091a6698 rip = 0x000000010419bf97 01:38:55 INFO - rsp = 0x00007fff5fbf7c50 rbp = 0x00007fff5fbf7e10 01:38:55 INFO - Found by: call frame info 01:38:55 INFO - 4 XUL!GCCycle [jsgc.cpp:3f8e27e02893 : 4858 + 0x10] 01:38:55 INFO - rbx = 0x000000000000002c r12 = 0x00000001091a6200 01:38:55 INFO - r13 = 0x0000000000000000 r14 = 0x0000000105520183 01:38:55 INFO - r15 = 0x0000000000000000 rip = 0x000000010419a2c3 01:38:55 INFO - rsp = 0x00007fff5fbf7e20 rbp = 0x00007fff5fbf7e80 01:38:55 INFO - Found by: call frame info From: https://tbpl.mozilla.org/php/getParsedLog.php?id=36790332&tree=Mozilla-Inbound#error0
The problem is a combination of the fact that the callback into the browser that happens when a GC has finished can cause allocation to happen in the nursery and that that in Collect() we can run the major GC more than once in some situations. If the callback allocates and then we run another major GC, this assertion will fire. The solution is to move the minor GC into the loop so that it always runs before major GC. If we need to re-run the major GC the nursery will almost always be empty anyway so this is not a performance concern. I also added some more assertions to make sure the nursery is always empty when we expect it to be.
Attachment #8398450 - Flags: review?(terrence)
Comment on attachment 8398450 [details] [diff] [review] bug988821-nurseryIsEmptyAssertion Review of attachment 8398450 [details] [diff] [review]: ----------------------------------------------------------------- r=me
Attachment #8398450 - Flags: review?(terrence) → review+
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: