...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?
10 years ago
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
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.