Closed Bug 475199 Opened 12 years ago Closed 12 years ago
20090124 nightly crashes on start for PPC Mac (mozilla-central and mozilla-1
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090123 Shiretoko/3.1b3pre Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090124 Shiretoko/3.1b3pre Checked for updates and received notice of "major update" test. Selected "Get New Version", which downloaded as expected. Shiretoko prompted to restart; it crashed and exited within 20 seconds. Subsequent attempts to launch program continued to fail. Reverted to 1-23 build. Reproducible: Always Steps to Reproduce: 1. Download 1-24 nightly 2. Tell Shiretoko to restart 3.
WFM on Intel. Does the crash reporter fire at all ? You can get the crash id's even if Firefox won't start: http://support.mozilla.com/en-US/kb/Mozilla+Crash+Reporter#Viewing_reports_outside_of_Firefox It may not be related to the major update at all. Do you get the crash if you d/l the 20090124 dmg, unpack, and run it ? This is the list of changes between the mac nightlies of 23rd and 24th: http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?fromchange=700a7c1a4caa&tochange=d00b0d0d4b64 Perhaps there is some PPC specific bustage there, wouldn't be the first time.
See also bug 475206
Crash ID from "InstallTime20090124020525": 1232832543 Will try installing from 1-24 dmg and report back.
Hmm, doesn't look like the usual crash IDs. There are a few dep builds from 20090123 left at http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-1.9.1-macosx/ which might help narrow it down a bit, but move fast as they are removed after 24 hours.
Same non-start from directly downloaded 1-24 build, so you're right -- nothing to do with the major update test. I'm a noob at this -- should I mark this one as resolved and file a new bug? Going to grab those other builds and see if I can identify the problem.
Updating summary & status based on information here & in bug 475206.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: 20090124 major update test build crashed on start → 20090124 nightly crashed on start for PPC Mac (mozilla-central and mozilla-1.9.1)
On mozilla-1.9.1, changes between 20090123 nightly and build ending 20:18 ish on 23rd is http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?fromchange=700a7c1a4caa&tochange=ca801f82facf On mozilla-central, changes between 20090123 and 24 nightlies is http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e1962b8ae522&tochange=e6693f9fb089 The intersection is * Natch — Bug 474964 - comment nodes screw up the tab bar. r=gavin * Benjamin Smedberg — Bug 475027 - only MSVC needs jscpucfg.h... everyone else should be using jsautocfg.h and the configure-generated defines. If you're doing something crazy like cross-compiling from FreeBSD to Windows using MSVC, this will make your life happier r=crowder * Mats Palmgren — Test for bug 446328 * Steven Michaud — NPP_SetWindow()'s window->clipRect.top off by 22 pixels in CoreGraphics mode. b=474491 r=josh sr=roc * Boris Zbarsky — Bug 474389. Fix the 'set up editor after this load' setup, which hasn't really worked for a while, except for initial loads in the window. r+sr=peterv * Boris Zbarsky — Bug 459443. Make sure to detach our editor even if we don't have a session history entry, so that scripts will get correctly reenabled. r+sr=peterv Which suggests bug 474491 or maybe bug 475027; CC'ing liberally.
Severity: critical → blocker
Component: Build Config → General
QA Contact: build.config → general
Summary: 20090124 nightly crashed on start for PPC Mac (mozilla-central and mozilla-1.9.1) → 20090124 nightly crashes on start for PPC Mac (mozilla-central and mozilla-1.9.1)
This regressed today on trunk as well as branch? I can reproduce using Rosetta.
FWIW, I'd be very suprised if bug 475027 caused this, but I'd be less surprised if it were caused by Bug 269538 which I landed on branch yesterday, but on trunk on the 22nd.
Bug 475206 comment #3 says both trunk and branch.
(In reply to comment #12) > Bug 475206 comment #3 says both trunk and branch. ... and apparently started a day earlier on trunk, matching up with bug 269538 landings.
Here are two Breakpad crash ids -- one made with the 2009-01-23 Minefield nightly, the other with the 2009-01-24 Shiretoko nightly. bp-38454061-d5c7-4c9b-8928-a8cfd2090124 bp-186415f2-2dc3-4208-8391-a30432090124 I got them by running the nightlies in gdb. But (oddly) when the crash came, there was no break in gdb -- instead (in both cases) Breakpad came up.
By the way (for the record), there was nothing in the system console.
Oddly, there's no crash with a debug build made (on my G4) from current trunk code.
This should almost certainly block beta 3.
Priority: -- → P1
Target Milestone: --- → Firefox 3.1b3
I'll try to take this. But if I can't reproduce it running a self-build in Rosetta I might be stuck.
Assignee: nobody → benjamin
Flags: blocking-firefox3.1? → blocking-firefox3.1+
Is this 10.5 PPC only, or does it happen on 10.4 PPC also?
I've reproduced it on PPC 10.4.11.
Just tried 1-24 trunk and branch on 10.4.11 -- both failed the same way as on my machine running 10.5.6.
The only way I've been able to reproduce this crash with self-made builds (of current trunk code) is as follows: 1) Do a universal build. (So far I've only done this on an X86 box.) 2) Change to the ppc or i386 directory under the objdir and run "make package". 3) Open the resulting dmg file (in ppc/dist or i386/dist) on my PPC Mac, copy the distro from it the hard drive, and run it there. My mozconfig file is pretty standard. But even so I tried a few variations on it, aways with the same result. export CFLAGS="-g -gfull" export CXXFLAGS="-g -gfull" . $topsrcdir/browser/config/mozconfig . $topsrcdir/build/macosx/universal/mozconfig mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-firefox-univ mk_add_options MOZ_MAKE_FLAGS=-j2 mk_add_options AUTOCONF=autoconf213 ac_add_options --enable-application=browser ac_add_options --enable-optimize ac_add_options --disable-debug ac_add_options --disable-tests ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.4u.sdk The mozconfig file used to do official nightly builds is very similar, and (of course) has the same results: . $topsrcdir/build/macosx/universal/mozconfig ac_add_options --enable-application=browser ac_add_options --enable-update-channel=nightly ac_add_options --enable-update-packaging ac_add_options --disable-tests ac_add_options --enable-codesighs export CFLAGS="-gdwarf-2" export CXXFLAGS="-gdwarf-2" # Needed to enable breakpad in application.ini export MOZILLA_OFFICIAL=1 # Enable parallel compiling mk_add_options MOZ_MAKE_FLAGS="-j4" Needless to say, this has me completely stumped :-(
(Following up comment #22) For the record, the Intel Mac on which I've done these universal builds has gcc 4.0.1 from XCode 3.0. I haven't changed my XCode version for a long time.
(Following up comment #22) I tried a whole bunch of different kinds of builds on my PPC Mac -- some non-opt and some opt, with several variations in the .mozconfig file. None of them crashed when run from the build directory. And where "make package" worked (with the non-debug builds), none of the packaged distros crashed. The only variation I haven't (yet) tried on my PPC Mac is a universal build ... which will take hours, since my old G4 is so slow.
(In reply to comment #22) Have you tried setting your Intel-Universal-build to run under Rosetta on your Intel box (using Get Info on the .app), as hinted at by bsmedberg ? That gives the crash on my Intel machine with the tinderbox build.
Yup. My universal builds (made as I described in comment #22) also crash (in the same way) on my Intel Mac when run under Rosetta.
Another thing: Just checked all the binaries in one of my universal builds (which crashes on a PPC Mac or under Rosetta), and they're all universal binaries with 2 architectures (ppc and i386) -- as they should be.
just saw this bug. I believe the QA lab has a ppc 10.4 machine, so we can try this out in the morning to see if we can assist with more info.
If the problem really is bug 269538, then it might suffice for someone who has a PPC build that crashes to simply attach their $obj/js/src/mozilla-config.h, $obj/js/src/js-config.h, and $obj/js/src/config/autoconf.mk files; we can just look for some value that's wrong for PPC.
I inadvertantly moved the JS_STACK_GROWTH_DIRECTION check in jscpucfg.cpp from outside the cross-compile checks to inside. For some reason, the C preprocessor didn't complain about the undefined symbol. I've commited this patch to revert to the prior behavior. This fixes PPC locally.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
(In reply to comment #30) > > I inadvertantly moved the JS_STACK_GROWTH_DIRECTION check in jscpucfg.cpp from > outside the cross-compile checks to inside. For some reason, the C preprocessor > didn't complain about the undefined symbol. If a macro is not defined, the C preprocessor gives it the default value of 0L. Since we only test JS_STACK_GROWTH_DIRECTION like this: #if JS_STACK_GROWTH_DIRECTION < 0 or this: #if JS_STACK_GROWTH_DIRECTION > 0 an undefined JS_STACK_GROWTH_DIRECTION won't break those tests.
Could be worth it to toss an #ifndef JS_STACK_GROWTH_DIRECTION #error before those tests.
Just adding additional comments here. I am running a PPC G4, OSX 10.5.3, and have both the 1.9.1 latest branch and 3.2a1pre trunk nightlies downloaded directly from the nightly ftp (1/26/08). Clicking on either app will open the icon, bounce on the taskbar 3 times, and immediately go away. No crash report thrown, and only the console.log writes: 1/26/09 4:50:22 PM com.apple.launchd ([0x0-0x2b02b].org.mozilla.firefox) Exited with exit code: 1 I'll test this fix on the next build with benjamin's patch.
verified fixed on the 1.9.1 branch using Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090127 Shiretoko/3.1b3pre as well as the 10.4.11 nightly build. verified fixed on the trunk using Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090127 Minefield/3.2a1pre
You need to log in before you can comment on or make changes to this bug.