Closed Bug 232972 Opened 22 years ago Closed 21 years ago

MacOS X trunk builds (1.7a) won't start

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: ole, Assigned: leaf)

References

Details

User-Agent: Build Identifier: http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest/ Browser will not start Reproducible: Always Steps to Reproduce: 1. Replaced earlier version (1.6b) with 1.7b 2. Tried launching 3. Program hangs Actual Results: Nothing Expected Results: Should have started PoweMac G5 dual 2Ghz
WFM Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7a) Gecko/20040202 (there's not yet a 1.7b ;)
Moz 2004020308 wfm on XP Pro. OS X only?
FYI : got PM from reporter, he is using OS X 10.3.2
*** Bug 233241 has been marked as a duplicate of this bug. ***
Confirmed on Mac OS X 10.2.3. I have the same stacktrace as can be found in bug 233241 : #0 0x8fe01220 in halt #1 0x8fe10654 in link_in_need_modules #2 0x8fe10270 in bind_lazy_symbol_reference #3 0x8fe00e60 in stub_binding_helper_interface #4 0x0128f188 in _ZN11nsRegionMac8GetRectsEPP15nsRegionRectSet #5 0x00ea3ac4 in _Z30ConvertNativeRegionToAppRegionP9nsIRegionP8nsRegionP16nsIDeviceContext #6 0x00ea3d70 in _ZN13nsViewManager7RefreshEP6nsViewP19nsIRenderingContextP9nsIRegionj #7 0x00ea6ba8 in _ZN13nsViewManager13DispatchEventEP10nsGUIEventP13nsEventStatus #8 0x00e9fc34 in _Z11HandleEventP10nsGUIEvent #9 0x0092ad1c in _ZN8nsWindow13DispatchEventEP10nsGUIEventR13nsEventStatus #10 0x0092ade4 in _ZN8nsWindow19DispatchWindowEventER10nsGUIEventR13nsEventStatus #11 0x0092a890 in _ZN8nsWindow12UpdateWidgetER6nsRectP19nsIRenderingContext #12 0x0092a9a8 in _ZN8nsWindow12UpdateWidgetER6nsRectP19nsIRenderingContext #13 0x0092a0a4 in _ZN8nsWindow19PaintUpdateRectProcEtP15OpaqueRgnHandlePK4RectPv #14 0x0092a4b0 in _ZN8nsWindow17HandleUpdateEventEP15OpaqueRgnHandle #15 0x00912a44 in _ZN17nsMacEventHandler11UpdateEventEv #16 0x00911418 in _ZN17nsMacEventHandler13HandleOSEventER11EventRecord #17 0x00919920 in _ZN11nsMacWindow13DispatchEventEPvPi #18 0x00915768 in _ZN16nsMacMessagePump23DispatchOSEventToRaptorER11EventRecordP15OpaqueWindowPtr #19 0x00914b04 in _ZN16nsMacMessagePump8DoUpdateER11EventRecord #20 0x009149a4 in _ZN16nsMacMessagePump13DispatchEventEiP11EventRecord #21 0x00914790 in _ZN16nsMacMessagePump13DoMessagePumpEv #22 0x009082d0 in _ZN10nsAppShell3RunEv #23 0x0000bd00 in _Z5main1iPPcP11nsISupports #24 0x0000c24c in main #25 0x00008ab0 in _start #26 0x8fe190f4 in _dyld_start The console-log contains more details : dyld: /Applications/Mozilla.app/Contents/MacOS/mozilla-bin Undefined symbols: /Applications/Mozilla.app/Contents/MacOS/components/libgfx_mac.dylib undefined reference to _PR_Realloc expected to be defined in Carbon Feb 6 20:57:17 localhost crashdump: Crash report written to: /Users/jhermans/Library/Logs/CrashReporter/mozilla-bin.crash.log The last build that worked for me is 2004-02-03-05-trunk
Status: UNCONFIRMED → NEW
Ever confirmed: true
is this caused by bug 227537 ?
Anybody know what machine produces the mac nightlies?
Flags: blocking1.7a+
Summary: Latest build of 1.7b won't start → MacOS X trunk builds (1.7a) won't start
(In reply to comment #5) > Confirmed on Mac OS X 10.2.3. I have the same stacktrace as can be found in bug [stacktrace deleted ...] > /Users/jhermans/Library/Logs/CrashReporter/mozilla-bin.crash.log > > > The last build that worked for me is 2004-02-03-05-trunk I have contradicting reports ... 1. - G3 Minitower running - Mac OS X 10.2.8 builds after 200-02-03-05 fail to start ... in fact they fail to display the profile selection window in full ... only an outline appears and then Mozilla quits. 2. On the other hand, this tmorning - 700 MHz G4 eMac - Mac OS X v10.3.2 I am running build 2004-02-05-05 which fails on the Minitower. That's what's new for this bug for me ... Dale
(In reply to comment #8) > (In reply to comment #5) > > Confirmed on Mac OS X 10.2.3. I have the same stacktrace as can be found in bug That is actually 10.2.8 ... > > The last build that worked for me is 2004-02-03-05-trunk > > I have contradicting reports ... > > 1. - G3 Minitower running > - Mac OS X 10.2.8 > builds after 200-02-03-05 fail to start ... > in fact they fail to display the profile selection window in full ... > only an outline appears and then > Mozilla quits. That's the bug that I'm seeing, on a iBook 300 MHz.
(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #5) [deletion...] > > > > The last build that worked for me is 2004-02-03-05-trunk > > > > I have contradicting reports ... > > > > 1. - G3 Minitower running > > - Mac OS X 10.2.8 > > builds after 200-02-03-05 fail to start ... > > in fact they fail to display the profile selection window in full ... > > only an outline appears and then > > Mozilla quits. > > That's the bug that I'm seeing, on a iBook 300 MHz. Another count against G3 and/or MacOSX 10.2.8. I also have a little more info from the eMac ... I have now run through the 20040205, 20040206, and 20040207 Mac OS X builds and all of them run on the eMac (G4). Dale
Still seeing the same behaviour with Seamonkey 2004-02-09-05-trunk (Mac OS X 10.2.8, G3) Mozilla Firefox 0.8 (build 20040206) works fine.
Assignee: general → leaf
Accepting (sigh)
Status: NEW → ASSIGNED
anyone know of mac builds working yet?
I'm still unable to run the latest version (2004-02-14-05-trunk). I'm not sure why it hasn't been reported more, maybe because it only seems to happen on the Mac OS 10.2.8 / G3 combination ? The stacktrace is always the same : it crashes in nsRegionMac::GetRects <http://lxr.mozilla.org/seamonkey/source/gfx/src/mac/nsRegionMac.cpp#253>, because PR_Realloc couldn't be loaded.
Reproduced also with 14-Feb-2004 build on Mac OS 10.2.8, PowerBook G4. stacktrace is the same above.
(In reply to comment #7) > Anybody know what machine produces the mac nightlies? hilo, in the mofo office, produces the mac nightlies. It also produces the firefox build that hang, so i'm guessing this is machine dependent, though the seamonkey builds took longer to stop running than the firefox builds. I'm digging at this today.
i've created some test builds on a 10.2.8 machine: http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-1.7a-OSX10.2.8-test can a reporter please test this build?
(In reply to comment #17) > i've created some test builds on a 10.2.8 machine: > http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-1.7a-OSX10.2.8-test > > can a reporter please test this build? I test this build(BuildID: 2004021618) on MacOSX10.2.8(PowerMac G4). It seems that this build works fine. At least, this build can start.
The build at /pub/mozilla.org/mozilla/nightly/latest-1.7a-OSX10.2.8-test (with Build ID 2004021701) seem to work fine on a 400 MHz PowerPC G4 with Mac OS 10.2.8.
(In reply to comment #17) > http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-1.7a-OSX10.2.8-test The test build 2004021701 works for me too, on OS 10.2.8, PB G4.
(In reply to comment #17) > i've created some test builds on a 10.2.8 machine: > http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-1.7a-OSX10.2.8-test > > can a reporter please test this build? Yes, this opens fine with my beige G3 and 10.2.8.
(In reply to comment #17) > i've created some test builds on a 10.2.8 machine: > http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-1.7a-OSX10.2.8-test > > can a reporter please test this build? Works for me too - Mac OS X 10.2.8 / tangerine iBook (G3/300)
See related bug 233574 (firefox crash occurs in xpinstall, but missing symbols are still the cause).
minus blocking 1.7a since it seems to be working there now.
Flags: blocking1.7a+ → blocking1.7a-
plussing again, since it doesn't seem like the regular builds are fixed. bryner and pinkerton seem to know a way to make this work on a Panther machine.
Flags: blocking1.7a- → blocking1.7a+
We need to switch the release build configuration to use the --with-macos-sdk option that pinkerton and I added support for, or move the release builds to a 10.2 machine.
Flags: blocking1.7a+ → blocking1.7a-
Fix in comment 17 works for me, on 10.2.8, no nightly builds I've tried since early Feb work...
I've been having problems with Tbird .5 and Moz 1.6 "Nightlies" from 2/14/2004 on. G4-50o 1.5 Gb system Ram ATI Radeon 9000 Pro AGP Video Card OSX.2.8 system
slight correction to previous comment Machine is G4-500, not G4-50o
slight correction to previous comment Machine is G4-500, not G4-50o
my debug build from around February 12 is working fine; the nightly downloads from Feb06 to present crash on startup (Feb03 launches).
Nightlies are crashing for me with the same backtrace; PB G4/800Mhz. The images mentioned in comment 17 work around this problem for me too (I'm on 10.2.6). Thanks for providing the alternate builds.
I am running Mac OS X 10.3.2 on a B/W G3-350 with 512 MB. Could this bug be partially related to a G3 processor issue, seperate from the 10.2.8 issue? I downloaded the suite nightly from February 11 and have experienced : 1. Several glitches (quirks I do not normally experience such as the cursor rapidly switching between the text cursor and the pointing finger cursor when hovering over a Web page and stoping when not hovering over Mozilla such as hovering over the desktop or the dock. Also Mozilla "feels" (this is hard to put into words and must be experienced) more unstable than usual.) Mozilla feels "sick" like when I force myself to go to work with a head cold, I can still work, but I am not feeling my usual self. 2. As well I have experienced one (possibly two [can not remember]) kernel panics. I have not experienced a kernel panic since installing 10.1.5. Mozilla was the only program launched at the time. In my experience it appeared that Mozilla was causing some sort of instability in the OS. 3. With the Feb 11th nightly Mozilla began to use ~95-100mb of memory as reported by the activity monitor. With my experiences with the Feb 11th nightly I decided to download thew build for 10.2.8 (see comment 17). This build runs very well on my G3 using 10.3.2. The sluggishness and quirks are now gone. This appears to be a very stable build. Am I seeing the same bug. or another bug? Is this a bug which will not allow Mozilla to launch to 10.2.8 and at the same time launch and run on 10.3.2 but with quirks and instabilities when run on a G3 processor? Anyway so far all the issues I experienced with the Feb 11 nightly are solved when I run the build 2004021810 build on a 10.2.8 machine.
So, as of the 2004-02-17 builds, it's using the Xcode cross-development SDK, so the build should run on 10.1 / 10.2 as well as Panther. Are people still seeing problems with the _Seamonkey_ (not Firefox, it's a different problem) builds after 2004-02-17?
The most recent MacOSX Mozilla build available (2/25) works for me. The previous builds (2/6 through 2/14) do not work.
So far, 2004-02-25 build works fine on my beige G3 and 10.2.8.
ok, marking fixed, since bryner's sdk installation seems to have done the trick.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
This bug is not fixed. Machine Dual G5, 2Ghz. OS: 10.3.3 Console log: /Volumes/Mozilla/Mozilla.app/Contents/MacOS/mozilla-bin: can't map file: /Volumes/Mozilla/Mozilla.app/Contents/MacOS/plugins/Default Plugin.plugin ((os/kern) invalid argument) /Volumes/Mozilla/Mozilla.app/Contents/MacOS/mozilla-bin: can't map file: /Library/Internet Plug-Ins/Java Applet.plugin ((os/kern) invalid argument)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Sorry, that should be the latest 1.7b (not a)
Ole: that's another problem (bug 237926), only present in Mac OS X 10.3.3. This bug showed a stacktrace as in comment 5, and is really fixed.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → FIXED
(In reply to comment #40) > Ole: that's another problem (bug 237926), only present in Mac OS X 10.3.3. This > bug showed a stacktrace as in comment 5, and is really fixed. Oops, that bug 237826
*** Bug 245116 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.