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)

x86
macOS
defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 489647

People

(Reporter: mossop, Assigned: nthomas)

Details

Attachments

(1 file)

Both these slaves are timing out. None of the recent checkins should have affected mochitests.
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
See also bug 488345
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]
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.
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
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
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
Component: Release Engineering: Maintenance → Release Engineering
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.