Closed
Bug 489676
Opened 15 years ago
Closed 15 years ago
fx-win32-1.9-slave07 and fx-win32-1.9-slave08 failing in mochitests for no apparent reason
Categories
(Release Engineering :: General, defect, P2)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 489647
People
(Reporter: mossop, Assigned: nthomas)
Details
Attachments
(1 file)
38.10 KB,
text/plain
|
Details |
Both these slaves are timing out. None of the recent checkins should have affected mochitests.
Assignee | ||
Comment 1•15 years ago
|
||
We're getting crashes in mochitest, over to us to try to get a stack but dev help trying to reproduce would be very helpful too.
Assignee: server-ops → nobody
Component: Server Operations: Tinderbox Maintenance → Release Engineering: Maintenance
QA Contact: mrz → release
Assignee | ||
Comment 2•15 years ago
|
||
See also bug 488345
Assignee | ||
Comment 3•15 years ago
|
||
This looks closely related to bug 489322 / bug 489647, only it's in ClearAllTextRunReferences instead of ClearTextRun. Thread 0 (crashed) 0 xul.dll!ClearAllTextRunReferences [nsTextFrameThebes.cpp:3.188 : 314 + 0x0] eip = 0x1023065b esp = 0x0012fbd0 ebp = 0x0012fbe4 ebx = 0x07729818 esi = 0x064d6f50 edi = 0x00000000 eax = 0x095eb978 ecx = 0x01a7f9e0 edx = 0x10751568 efl = 0x00210206 1 xul.dll!UnhookTextRunFromFrames [nsTextFrameThebes.cpp:3.188 : 338 + 0xa] eip = 0x102306ac esp = 0x0012fbd4 ebp = 0x0012fbe4 2 xul.dll!FrameTextRunCache::NotifyExpired(gfxTextRun *) [nsTextFrameThebes.cp p:3.188 : 372 + 0xb] eip = 0x10233ee8 esp = 0x0012fbec ebp = 0x0012fc0c 3 xul.dll!nsExpirationTracker<gfxFont,3>::AgeOneGeneration() [nsExpirationTrac ker.h : 210 + 0xa]
Assignee | ||
Comment 4•15 years ago
|
||
dholbert, do you expect the crash here to be fixed on CVS HEAD now ? There were no mochitest problems in the three builds since it landed at 10:18, but that's not yet statistically significant given the intermittent crashes we were getting before.
Comment 5•15 years ago
|
||
Yeah, I'd expect that it'd be fixed. The old code that bug 489647 just updated was also determined to have been the cause of random oranges on mozilla-central[1], so it would make sense that the patch would correct random oranges on 1.9.0.x, too. [1] source: bug 467150 comment 3, 4, and 5
Assignee | ||
Comment 6•15 years ago
|
||
Steps to get a stack on 3.0 unit tests: # slave specific cd /e/slave/trunk_win3k3_8/mozilla ## generate symbols, had to clobber to get around nss build issue where nsinstall couldn't find a dll echo "export MOZ_DEBUG_SYMBOLS=1" >> .mozconfig make -f client.mk 2>&1 | tee build.log cd objdir make buildsymbols 2>&1 | tee ../buildsymbols.log # create fresh profile cd /e/slave/trunk_2k3_8/ python mozilla\\testing\\tools\\profiles\\createTestingProfile.py --clobber --binary mozilla\\objdir\\dist\\bin\\firefox.exe # run mochitest export MOZ_CRASHREPORTER_NO_REPORT=1 export MOZ_CRASHREPORTER=1 cd /e/slave/trunk_2k3_8/mozilla/objdir/_tests/testing/mochitest python runtests.py --autorun --console-level=INFO --close-when-done 2>&1 | tee <somelogfile> # repeat until you get the crash, check the log file for exit status # on crash # identify up the dump file in mochitesttestingprofile/minidumps /c/Utilities/minidump_stackwalk.exe mochitesttestingprofile\\minidumps\\d4a4164d-de3f-48bb-9d75-8e6bae508f46.dmp ..\\..\\..\\dist\\crashreporter-symbols\\2009042219 2>&1 | tee crash2.log
Assignee | ||
Comment 7•15 years ago
|
||
No problems with mochitest in the 17 builds on slave07/08/09 since the fix landed.
Assignee: nobody → nthomas
Status: NEW → RESOLVED
Closed: 15 years ago
Priority: -- → P2
Resolution: --- → DUPLICATE
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•