Closed Bug 1065539 Opened 11 years ago Closed 6 years ago

Intermittent test_aboutmemory6.xul | Test timed out | test_dumpGCAndCCLogsToFile.xul | [SimpleTest.finish()] No checks actually run | This test left crash dumps behind, but we weren't expecting it to!

Categories

(Toolkit :: about:memory, defect, P3)

x86_64
Linux
defect

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: RyanVM, Unassigned)

Details

(Keywords: intermittent-failure)

https://tbpl.mozilla.org/php/getParsedLog.php?id=47744909&tree=Mozilla-Inbound Ubuntu VM 12.04 x64 mozilla-inbound opt test mochitest-other on 2014-09-09 19:37:58 PDT for push bf3cb1e5ea63 slave: tst-linux64-spot-873 19:58:13 INFO - 1512 INFO must wait for load 19:58:13 INFO - 1513 INFO TEST-PASS | chrome://mochitests/content/chrome/toolkit/components/aboutmemory/tests/test_aboutmemory6.xul | two log entries generated 19:58:13 INFO - 1514 INFO TEST-PASS | chrome://mochitests/content/chrome/toolkit/components/aboutmemory/tests/test_aboutmemory6.xul | GC log file exists 19:58:13 INFO - 1515 INFO TEST-PASS | chrome://mochitests/content/chrome/toolkit/components/aboutmemory/tests/test_aboutmemory6.xul | CC log file exists 19:58:13 INFO - 1516 INFO TEST-PASS | chrome://mochitests/content/chrome/toolkit/components/aboutmemory/tests/test_aboutmemory6.xul | two log entries generated 19:58:13 INFO - 1517 INFO TEST-PASS | chrome://mochitests/content/chrome/toolkit/components/aboutmemory/tests/test_aboutmemory6.xul | GC log file exists 19:58:13 INFO - 1518 INFO TEST-PASS | chrome://mochitests/content/chrome/toolkit/components/aboutmemory/tests/test_aboutmemory6.xul | CC log file exists 19:58:13 INFO - 1519 INFO MEMORY STAT vsize after test: 1579110400 19:58:13 INFO - 1520 INFO MEMORY STAT residentFast after test: 421740544 19:58:13 INFO - 1521 INFO MEMORY STAT heapAllocated after test: 224068624 19:58:13 INFO - 1522 INFO TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/toolkit/components/aboutmemory/tests/test_aboutmemory6.xul | Test timed out. - expected PASS 19:58:13 INFO - 1523 INFO TEST-OK | chrome://mochitests/content/chrome/toolkit/components/aboutmemory/tests/test_aboutmemory6.xul | took 314018ms 19:58:13 INFO - Not taking screenshot here: see the one that was previously logged 19:58:13 INFO - 1524 INFO TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/toolkit/components/aboutmemory/tests/test_aboutmemory6.xul | Test timed out. - Result logged after SimpleTest.finish() 19:58:13 INFO - 1525 INFO TEST-START | chrome://mochitests/content/chrome/toolkit/components/aboutmemory/tests/test_dumpGCAndCCLogsToFile.xul 19:58:13 INFO - Xlib: extension "RANDR" missing on display ":0". 19:58:13 INFO - Xlib: extension "RANDR" missing on display ":0". 19:58:13 INFO - Xlib: extension "RANDR" missing on display ":0". 19:58:13 INFO - 1526 INFO TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/toolkit/components/aboutmemory/tests/test_dumpGCAndCCLogsToFile.xul | [SimpleTest.finish()] No checks actually run. (You need to call ok(), is(), or similar functions at least once. Make sure you use SimpleTest.waitForExplicitFinish() if you need it.) - expected PASS 19:58:13 INFO - 1527 INFO TEST-OK | chrome://mochitests/content/chrome/toolkit/components/aboutmemory/tests/test_dumpGCAndCCLogsToFile.xul | took 1990ms 19:58:15 INFO - 1528 INFO TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/toolkit/components/aboutmemory/tests/test_dumpGCAndCCLogsToFile.xul | [SimpleTest.finish()] No checks actually run. (You need to call ok(), is(), or similar functions at least once. Make sure you use SimpleTest.waitForExplicitFinish() if you need it.) - Result logged after SimpleTest.finish()
Summary: Intermittent test_aboutmemory6.xul | Test timed out | test_dumpGCAndCCLogsToFile.xul | [SimpleTest.finish()] No checks actually run → Intermittent test_aboutmemory6.xul | Test timed out | test_dumpGCAndCCLogsToFile.xul | [SimpleTest.finish()] No checks actually run | This test left crash dumps behind, but we weren't expecting it to!
Is there a way to get the stack trace for the crash?
(In reply to Eric Rahm [:erahm] from comment #12) > Is there a way to get the stack trace for the crash? There's a stack in the treeherder log after the PROCESS-CRASH line. The one from comment #11 is: 10:51:45 INFO - Crash reason: EXCEPTION_BREAKPOINT 10:51:45 INFO - Crash address: 0x3a32e9 10:51:45 INFO - Assertion: Unknown assertion type 0x00000000 10:51:45 INFO - Thread 0 (crashed) 10:51:45 INFO - 0 mozglue.dll!moz_abort [jemalloc_config.c:2d2577321beb : 50 + 0x34] 10:51:45 INFO - eip = 0x003a32e9 esp = 0x0012f564 ebp = 0x0012f5e0 ebx = 0x00000001 10:51:45 INFO - esi = 0x05c00b5c edi = 0x05e000c4 eax = 0x00000000 ecx = 0x00980ad9 10:51:45 INFO - edx = 0x00a40ea0 efl = 0x00000212 10:51:45 INFO - Found by: given as instruction pointer in context 10:51:45 INFO - 1 mozglue.dll!arena_avail_tree_remove [jemalloc.c:2d2577321beb : 3256 + 0x14f] 10:51:45 INFO - eip = 0x003a3c84 esp = 0x0012f568 ebp = 0x0012f5e0 10:51:45 INFO - Found by: call frame info 10:51:45 INFO - 2 mozglue.dll!arena_run_dalloc [jemalloc.c:2d2577321beb : 3872 + 0x16] 10:51:45 INFO - eip = 0x003a6548 esp = 0x0012f5e8 ebp = 0x0012f604 10:51:45 INFO - Found by: call frame info 10:51:45 INFO - 3 mozglue.dll!arena_dalloc_small [jemalloc.c:2d2577321beb : 4616 + 0x8] 10:51:45 INFO - eip = 0x003a5300 esp = 0x0012f60c ebp = 0x0012f628 10:51:45 INFO - Found by: call frame info 10:51:45 INFO - 4 mozglue.dll!arena_dalloc [jemalloc.c:2d2577321beb : 4719 + 0xc] 10:51:45 INFO - eip = 0x003a51b6 esp = 0x0012f630 ebp = 0x0012f69c 10:51:45 INFO - Found by: call frame info 10:51:45 INFO - 5 mozglue.dll!je_free [jemalloc.c:2d2577321beb : 6459 + 0x6] 10:51:45 INFO - eip = 0x003aa10e esp = 0x0012f6a4 ebp = 0x0012f6ac 10:51:45 INFO - Found by: call frame info 10:51:45 INFO - 6 xul.dll!PLDHashTable::Finish() [pldhash.cpp:2d2577321beb : 368 + 0x8] 10:51:45 INFO - eip = 0x10130d66 esp = 0x0012f6b4 ebp = 0x0012f6c4 10:51:45 INFO - Found by: call frame info 10:51:45 INFO - 7 xul.dll!nsTHashtable<nsBaseHashtableET<nsPtrHashKey<PRThread>,nsRefPtr<nsThread> > >::~nsTHashtable<nsBaseHashtableET<nsPtrHashKey<PRThread>,nsRefPtr<nsThread> > >() [nsTHashtable.h:2d2577321beb : 415 + 0x5] 10:51:45 INFO - eip = 0x10100c6b esp = 0x0012f6cc ebp = 0x0012f6e8 10:51:45 INFO - Found by: call frame info 10:51:45 INFO - 8 xul.dll!_CRT_INIT [crtdll.c : 414 + 0x1] 10:51:45 INFO - eip = 0x12c02b1e esp = 0x0012f6d4 ebp = 0x0012f6e8 10:51:45 INFO - Found by: call frame info
So this feels like several different issues. It started as a series of two issues: - test_aboutmemory6.xul times out - test_dumpGCAndCCLogsToFile.xul finished without calling any checks Comment #1 is a timeout Comment #2 is a timeout, and then test_dumpGCAndCCLogsToFile.xul called finish a few times Comment #3 is the same as comment #0 Comment #4 is the same as comment #0, but now test_memoryReporters.xul has decided to join the party Comment #5 is the a slight variation, test_aboutmemory6.xul times out, test_memoryReporters.xul calls finish a few times Comment #6, comment #7 are unrelated Comment #8 - #11 are WinXP-32 debug only shutdown crashes most likely unrelated to this test specifically This leaves us with a few questions: #1 - Is the original issue still happening? Hard to say, the last report was 2015-03-08 #2 - Why is test_dumpGCAndCCLogsToFile.xul finishing w/o performing any checks? #3 - Why are test_dumpGCAndCCLogsToFile.xul and test_memoryReporters.xul calling finish multiple times? #4 - The shutdown crash is in an assert, but we’re not seeing an actual message logged. It would be really helpful to get that. I think we can answer #2 and #3 through code inspection. #1, only time will tell. #4 is interesting, but we need more info to get anywhere with it. I did a bit of code spelunking and found that it's happening during nsThreadManager's static dtor which gets hit after |exit| is called. Specifically it's the destruction of mThreadsByPRIndex [1] that is triggering the assert somewhere deep in jemalloc, at least for comment #11. [1] https://hg.mozilla.org/mozilla-central/annotate/4fb7ff694bf5/xpcom/threads/nsThreadManager.h#l113
(In reply to Eric Rahm [:erahm] from comment #14) > #2 - Why is test_dumpGCAndCCLogsToFile.xul finishing w/o performing any > checks? From a look at the test it shouldn't be possible for it to call SimpleTest.finish() without at least one is(). > #3 - Why are test_dumpGCAndCCLogsToFile.xul and test_memoryReporters.xul > calling finish multiple times? For the former, if dumpGCAndCCLogsToFile calls the finish callback multiple times that could happen. The latter appears to not be async, so that doesn't even make sense. Unless I'm missing something, something weird is going on with those errors.
(In reply to Jed Davis [:jld] {UTC-7} from comment #15) > (In reply to Eric Rahm [:erahm] from comment #14) > > #2 - Why is test_dumpGCAndCCLogsToFile.xul finishing w/o performing any > > checks? > > From a look at the test it shouldn't be possible for it to call > SimpleTest.finish() without at least one is(). > > > #3 - Why are test_dumpGCAndCCLogsToFile.xul and test_memoryReporters.xul > > calling finish multiple times? > > For the former, if dumpGCAndCCLogsToFile calls the finish callback multiple > times that could happen. The latter appears to not be async, so that > doesn't even make sense. > > Unless I'm missing something, something weird is going on with those errors. Well, I guess hypothetically it could be: - Previous test times out - New test starts - Previous test still calls finish This could result in both finishing twice and finishing w/ no checks. I'm not familiar enough w/ SimpleTest to know if that's possible though...
(In reply to Eric Rahm [:erahm] from comment #16) > Well, I guess hypothetically it could be: > - Previous test times out > - New test starts > - Previous test still calls finish > > This could result in both finishing twice and finishing w/ no checks. I'm > not familiar enough w/ SimpleTest to know if that's possible though... I think it's not? Loading SimpleTest.js creates a new SimpleTest object, so each test page should have separate state for things like the “already called finish!” check. But I'm not sure if I trust my knowledge of JS enough to be certain about that.
Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.
Priority: -- → P3
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.