Closed Bug 424435 Opened 16 years ago Closed 16 years ago

moz2 mozilla-central linux/winxp builds crash on startup

Categories

(Firefox Build System :: General, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: joduinn, Assigned: anodelman)

References

Details

...and have been doing this since  2008/03/20 12:14:43

If you look in http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1206040483.1206040574.7393.gz, you will see:
...
 - currentDate = 20080320_1214
qm-plinux-trunk02: 
		Started Thu, 20 Mar 2008 12:14:58
Running test tjss: 
		Started Thu, 20 Mar 2008 12:14:58
Segmentation fault (core dumped)
	Screen width/height:1280/1024
	colorDepth:24
	Browser inner width/height: 1024/653
	Browser outer width/height: 1024/768
Segmentation fault (core dumped)
WARNING: problem starting counter monitor
FAIL: browser crash
Failed tjss: 
		Stopped Thu, 20 Mar 2008 12:16:18
FAIL: failure to complete test: tjss



We see the same if we try running the browser manually. 

Interesting to note that at 2008/03/20 10:44:43, the build worked fine. For details, see
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1206035083.1206041280.9241.gz

The talos machines did not change in that time range. Did any code or configs change in mozilla-central in those time ranges?
Not a releaseengineering/talos bug, afaict, but not sure where this should be filed... if this is not config problem, can you reassign?
There are only two changesets in that range:

http://hg.mozilla.org/mozilla-central/?rev/895712d07d4c
http://hg.mozilla.org/mozilla-central/?rev/61007906a1f8

Both of which done by bsmedberg.  So moving assignment to him...
Assignee: nobody → benjamin
Just to confirm, this is all platforms, and it happens when you just start the browser, or do I need to follow some procedure after starting the browser?
I tried to reproduce this on my local Linux machine using the instructions at http://wiki.mozilla.org/StandaloneTalos

tsspider and tjss both completed successfully. I did get a bunch of "WARNING: failed to terminate: 8479" This was testing against the downloaded mozilla-central build.
I'm still seeing this on all the linux mozilla-central talos testers.  These machines are running Ubuntu 7.10.  It's not making it more than a couple of pages into the tjss test before it dumps core and quits.

I do have some further information as mac & win talos mozilla-central testers are now up.

The winxp mozilla-central testers also make it a few pages into tjss and then crash (raising the crash reporter application in this case).

The mac mozilla-central testers don't get a chance to start the tjss tests before they throw errors and quit:
dyld: lazy symbol binding failed: Symbol not found: __LSCopyDefaultSchemeHandlerURL
  Referenced from: ../Minefield.app/Contents/MacOS/XUL
  Expected in: /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices

dyld: Symbol not found: __LSCopyDefaultSchemeHandlerURL
  Referenced from: ../Minefield.app/Contents/MacOS/XUL
  Expected in: /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices


Should these be split into separate bugs per platform, or would you prefer to have them all together?
Summary: moz2 mozilla-central linux builds segfault on startup → moz2 mozilla-central linux/winxp/mac builds crash on startup
The mac one should be a different bug. Let's assume win/linux have the same root cause for now, even though I have no clue what that cause is, yet.
Follow mac issue in bug 424890.
Summary: moz2 mozilla-central linux/winxp/mac builds crash on startup → moz2 mozilla-central linux/winxp builds crash on startup
The mac bug is actually bug 423672, although if you're building with the 10.4u SDK, I don't see how you'd get that.

Alice, I tried this on Windows as well, using the standalone-talos instructions. tjss completed successfully, though twinopen threw a python exception:

  File "c:\Python24\lib\shutil.py", line 166, in rmtree
OSError: [Errno 13] Permission denied: 'c:\\users\bsmedb~1\\appdata\\local\\temp\\tmpyyx1-e\\profile\\Cache\\_CACHE_001_'

So I think that whatever is causing tjss to fail on the automated machines must be specific to them somehow: does it crash for you on a local machine? Are there configuration settings used on the automated machines that wouldn't be present in standalone Talos?

I'm going to punt this back to you for the moment since I can't reproduce.
Assignee: benjamin → anodelman
The cache thing was bug 424571: adding the pref from there allowed standalone talos to run to completion.
I have a crashing browser on qm-mini-moz2-xp01 in c:\talos-slave\firefox

I just grabbed a fresh build, opened it and watched it crash.  The build I used is here:

http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/firefox-4.0a1pre.en-US.win32.zip

This was running with a new profile.

Are we testing with builds from the same location?  Maybe that would explain why I'm seeing crashers and you aren't.
Well... I was using builds from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/

Perhaps this is a result of a bad depend build, and the nightlies (which are clobbers) are ok? Could you check my dir?
Alright, I've clobbered linux and win32 dep builds. New ones should be coming out shortly.
That seems to have fixed it - I see successful test runs for both mozilla-central winxp and linux on MozillaTest.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Component: Build Config → General
Product: Firefox → Firefox Build System
You need to log in before you can comment on or make changes to this bug.