Closed Bug 470864 Opened 17 years ago Closed 17 years ago

Crash [@nsObjCExceptionLogAbort][@ nsCocoaWindow::Show]

Categories

(Core :: Widget: Cocoa, defect, P1)

Product:
Core
Component:
Widget: Cocoa
Platform:
x86
macOS
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: dveditz, Assigned: smichaud)

Details

(Keywords: crash, fixed1.9.1)

Crash Data

Attachments

(3 files, 1 obsolete file)

Fix/workaround
4.14 KB, patch
jaas
: review+
roc
: superreview+
shaver
: approval1.9.1+
Details | Diff | Splinter Review
compilation errors resulting from this patch
3.25 KB, text/plain
Details
Log of compiling nsCocoaWindow.mm (showing no errors)
1.93 KB, text/plain
Details
I crashed @nsObjCExceptionLogAbort trying to open a PDF file using Preview as the helper-app. SS said I should file this. bp-b20b932a-6d01-448a-b8bd-33d8a2081222 Console.app says: 12/22/08 5:08:36 PM firefox-bin[1878] Mozilla has caught an Obj-C exception [NSInternalInconsistencyException: Error (1000) creating CGSWindow] In case the breakpad report gets purged: nsObjCExceptionLogAbort mozilla/widget/src/cocoa/nsCocoaWindow.mm:152 nsCocoaWindow::Show mozilla/widget/src/cocoa/nsCocoaWindow.mm:786 nsView::SetVisibility mozilla/view/src/nsView.cpp:473 nsViewManager::SetViewVisibility mozilla/view/src/nsViewManager.cpp:1736 nsMenuPopupFrame::AdjustView mozilla/layout/xul/base/src/nsMenuPopupFrame.cpp:331 nsPopupSetFrame::DoLayout mozilla/layout/xul/base/src/nsMenuBarFrame.cpp:213 nsIFrame::Layout mozilla/layout/xul/base/src/nsBox.cpp:561 nsSprocketLayout::Layout mozilla/layout/xul/base/src/nsSprocketLayout.cpp:523 nsBoxFrame::DoLayout mozilla/layout/xul/base/src/nsBoxFrame.cpp:946 nsIFrame::Layout mozilla/layout/xul/base/src/nsBox.cpp:561 nsStackLayout::Layout mozilla/layout/xul/base/src/nsStackLayout.cpp:288 nsBoxFrame::DoLayout mozilla/layout/xul/base/src/nsBoxFrame.cpp:946 nsIFrame::Layout mozilla/layout/xul/base/src/nsBox.cpp:561 nsBoxFrame::Reflow mozilla/layout/xul/base/src/nsBoxFrame.cpp:757 nsContainerFrame::ReflowChild mozilla/layout/generic/nsContainerFrame.cpp:771 ViewportFrame::Reflow mozilla/layout/generic/nsViewportFrame.cpp:286 PresShell::DoReflow mozilla/layout/base/nsPresShell.cpp:6288 PresShell::ProcessReflowCommands mozilla/layout/base/nsPresShell.cpp:6394 PresShell::DoFlushPendingNotifications mozilla/layout/base/nsPresShell.cpp:4576 PresShell::ReflowEvent::Run mozilla/layout/base/nsPresShell.cpp:6153 nsThread::ProcessNextEvent mozilla/xpcom/threads/nsThread.cpp:510 NS_ProcessPendingEvents_P nsThreadUtils.cpp:180 nsBaseAppShell::NativeEventCallback mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:121 nsAppShell::ProcessGeckoEvents mozilla/widget/src/cocoa/nsAppShell.mm:302 CoreFoundation@0x72614 CoreFoundation@0x72cf7 HIToolbox@0x2f47f
Got this twice more, I'm starting to wonder if Personas is involved, it's the only thing really different from what I was using before. bp-2d3d107c-2418-4d09-a534-7c00b2081223 bp-4e178c94-caa0-457a-a74b-d5d302081223 Both crashes have the same console message as above
Summary: Crash [@nsObjCExceptionLogAbort] opening PDF file. → Crash [@nsObjCExceptionLogAbort]
Since this is likely one of the many crashes in our Mac topcrash (nsObjCExceptionLogAbort), it should probably get investigated and fixed (and, thus, block).
Flags: blocking1.9.1?
FWIW, http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.1b2&platform=mac&query_search=stack&query_type=contains&query=nsCocoaWindow%3A%3AShow&date=&range_value=1&range_unit=weeks&do_query=1&signature=nsObjCExceptionLogAbort(NSException*) shows 81 crashes in the past week that start nsObjCExceptionLogAbort nsCocoaWindow::Show and then vary a bit thereafter (4-5 different varieties) http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.0.5&platform=mac&query_search=stack&query_type=contains&query=nsCocoaWindow%3A%3AShow&date=&range_value=1&range_unit=weeks&do_query=1&signature=nsObjCExceptionLogAbort(NSException*) has 905 crashes in the past week that start the same way; they vary more widely thereafter. Dan, are those PDFs you're opening attempting to open the PDF in a new window (i.e., the site author assuming everyone has a PDF plug-in installed, and doing the usual "let's open anything you click on in a separate window" thing)?
Summary: Crash [@nsObjCExceptionLogAbort] → Crash [@nsObjCExceptionLogAbort][@ nsCocoaWindow::Show]
I took the PDF part off. The first time I believe I was attempting to open a link in a new tab (cmd-click), which turned out to be a PDF so after the blank tab was created the helper-app dialog came up. I chose the Preview app and then Firefox went down. I have no idea why it was trying to create a window at that point, if anything it was closing the helper-app dialog. Unless it was trying to "show" the already existing browser (e.g. redraw the previously hidden part?). But the other crashes have had nothing to do with PDFs. One was trying to open the options dialog. One was again Cmd-clicking to open a page (not pdf) into a new tab, and another was clicking on a link to open in the same window. No real common pattern. This was already a topcrash, but not one I've ever experienced until now suddenly several in a few days. Am I just getting lucky or did a recent 1.9.0.x change make this tons worse? If the latter that's really scary since it was _already_ a topcrash.
Assignee: joshmoz → smichaud
Priority: -- → P1
dveditz - can you reproduce this at will? Can you reproduce it without any extensions enabled? Can anyone besides dveditz reproduce this at will?
Dveditz: Please answer Josh's questions, and here's one from me: Do you have more than one monitor? The following suggests this might make "Error (1000) creating CGSWindow" more likely to appear: http://lists.apple.com/archives/xcode-users/2006/Oct/msg00131.html
Here's an interesting thread on "Error (1000) creating CGSWindow": http://www.cocoabuilder.com/archive/message/cocoa/2007/11/1/191960 This error probably shouldn't be fatal. (I'm sure it isn't fatal in Safari, or in other more "standard" Cocoa apps. Though it does (according to this thread) appear to stop rendering.) Apple's David Duncan says it "indicates a general failure to create the window". nsCocoaWindow::Show() doesn't create any windows, but it does make windows visible that were previously hidden. So it should probably be possible to make the browser swallow these errors by wrapping calls to [NSWindow orderFront:] and [NSWindow makeKeyAndOrderFront:] in LOGONLY_BLOCKs. I'll create a patch that does this, along with a tryserver build. Dveditz can test it to see what he finds.
Dveditz, here's another thing you can try: Run a debug build in gdb and tell gdb to break on '+[NSException raise:format:arguments:]' If you trigger your crash inside gdb, it will first break at the line (inside nsCocoaWindow::Show()) where the "Error (1000) creating CGSWindow" happens. Please get a stack trace at this point and attach it here.
Attached patch Patch for debugging (obsolete) — — Splinter Review
Here's the patch I promised in comment #7. And here's a tryserver build made with it: https://build.mozilla.org/tryserver-builds/2009-01-08_10:06-smichaud@pobox.com-bugzilla470864-debug/smichaud@pobox.com-bugzilla470864-debug-firefox-try-mac.dmg Dveditz (and any others who've seen crashes in nsCocoaWindow::Show()), please try it and let us know your results.
blocking1.9.1- until we get more confirmations that this affects many people and we have more info in general. We can always put a fix in an update.
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
I get about 5-10 crashes about this every day. I downloaded the debug that Steven Michaud made. about:Crashes gives: 4b1e7ba7-f0d7-4aff-b3a8-5e9092090120 20/01/09 11:48 94fe196f-4164-4248-b949-70c472090120 20/01/09 11:48 27c8d6aa-0702-4385-bfa3-7a7222090120 20/01/09 11:48 61cccddc-34c4-4deb-8dcd-c77572090120 20/01/09 11:47 5f3f896a-8576-4e56-8df7-0b0ac2090120 20/01/09 11:47 da82d43d-194c-4a29-9176-e877c2090120 20/01/09 10:55 381dd246-944a-4465-92c5-d26722090120 20/01/09 10:55 cdf9a99f-50fc-4103-ad8f-460782090120 20/01/09 9:26 7738e712-f9d2-43b6-abc1-b8e7b2090119 19/01/09 21:56 7e5c4313-07ab-4dae-a1b8-689a32090119 19/01/09 11:06 6adda3e8-bdc5-46ba-bb3b-c26fc2090119 19/01/09 11:05 9e63613a-8093-449b-9b8d-9215e2090119 19/01/09 11:05 1c4c630e-1e88-4691-9969-7f8842090119 19/01/09 11:05 5c1bbad6-537a-409a-848b-e28172090119 19/01/09 11:05 53705db3-1511-43d1-ab72-bfc332090119 19/01/09 11:03 a1e5d47d-79aa-4ac5-b571-a4b982090119 19/01/09 10:25 b3a0f14d-04e3-4db4-bef8-192322090119 19/01/09 10:20 90c74be8-6188-4f97-b7c7-721f32090118 18/01/09 23:31 dcaf3748-0bc4-477b-aeb5-202c02090118 18/01/09 23:31 2d22fe07-eaf6-449b-967a-4b65b2090118 18/01/09 22:48 e1eb4404-7975-41c1-9900-faf072090118 18/01/09 18:52 ee2e562b-3d21-11dd-bf18-001cc45a2c28 18/06/08 12:33 ac80f411-3d20-11dd-84be-001cc4e2bf68 18/06/08 12:24
> I get about 5-10 crashes about this every day. I downloaded the debug that > Steven Michaud made. Are you saying you crash even with my tryserver build from comment #9?
no, i am sorry if i was unclear. With the default max OSX build i get those crashes. I downloaded your build when i wrote the last message, and i have been running your build ever since. No crashes with your build so far.
(In reply to comment #11) Only the following are this bug's crashes: 4b1e7ba7-f0d7-4aff-b3a8-5e9092090120 20/01/09 11:48 5f3f896a-8576-4e56-8df7-0b0ac2090120 20/01/09 11:47 da82d43d-194c-4a29-9176-e877c2090120 20/01/09 10:55 cdf9a99f-50fc-4103-ad8f-460782090120 20/01/09 9:26 7738e712-f9d2-43b6-abc1-b8e7b2090119 19/01/09 21:56 6adda3e8-bdc5-46ba-bb3b-c26fc2090119 19/01/09 11:05 2d22fe07-eaf6-449b-967a-4b65b2090118 18/01/09 22:48 The rest (with 2 exceptions) are the OnStopFrame() crash of bug 471101. In the future, please look at your crash logs more carefully. (The 2 exceptions are crashes that still haven't been processed, presumably because of server-side problems.) Bug 471101 has now been fixed, so I'm going to make a new tryserver build (one that contains the fix).
(In reply to comment #13) > No crashes with your build so far. I'm glad to hear it. Thanks for the info. But (to avoid confusion with bug 471101) I'm still going to do a new tryserver build. It should be available in the next few hours.
Here's a new tryserver build (made with my debugging patch from comment #9, attachment 356023 [details] [diff] [review]). Aside from the patch, it's made from current trunk code, and so includes the fix for bug 471101. https://build.mozilla.org/tryserver-builds/2009-01-20_08:59-smichaud@pobox.com-bugzilla470864-debug-c2/smichaud@pobox.com-bugzilla470864-debug-c2-firefox-try-mac.dmg Please test with this build, instead of the one from comment #9.
But the build from #9 has been rock solid.
> But the build from #9 has been rock solid. Very glad to hear it. Dveditz, it's your turn.
>> But the build from #9 has been rock solid. > > Very glad to hear it. Oops, didn't notice that you weren't testing with the comment #16 build. Please test with that. It's important.
I have been testing #16 for some hours. No problems so far.
> I have been testing #16 for some hours. No problems so far. Thanks!! Let us know if you ever do see this bug's crash using it. Dveditz, we really do need to hear from you. Please test with the patch (and tryserver build) from comment #16.
Still no problems
I hit this just now on Trunk: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090122 Minefield/3.2a1pre My STR was: 1) launch minefield 2) Open url: https://litmus.mozilla.org/manage_testcases.cgi?testcase_id=5186 3) Right click on the "Firefox3 web services" link in the testcase 4) Crashes. http://crash-stats.mozilla.com/report/index/9dfe0c4f-1c5f-43f9-8b5e-c28ec2090122 Frame Module Signature [Expand] Source 0 XUL nsObjCExceptionLogAbort nsObjCExceptions.h:152 1 XUL nsCocoaWindow::Show widget/src/cocoa/nsCocoaWindow.mm:780 2 XUL nsView::SetVisibility view/src/nsView.cpp:471 3 XUL nsViewManager::SetViewVisibility view/src/nsViewManager.cpp:1705 4 XUL nsMenuPopupFrame::AdjustView layout/xul/base/src/nsMenuPopupFrame.cpp:374 5 XUL nsPopupSetFrame::DoLayout layout/xul/base/src/nsPopupSetFrame.cpp:213 6 XUL nsIFrame::Layout layout/xul/base/src/nsBox.cpp:561 7 XUL nsSprocketLayout::Layout layout/xul/base/src/nsSprocketLayout.cpp:523 8 XUL nsBoxFrame::DoLayout layout/xul/base/src/nsBoxFrame.cpp:947 9 XUL nsIFrame::Layout layout/xul/base/src/nsBox.cpp:561 10 XUL nsStackLayout::Layout layout/xul/base/src/nsStackLayout.cpp:295 11 XUL nsBoxFrame::DoLayout layout/xul/base/src/nsBoxFrame.cpp:947 12 XUL nsIFrame::Layout layout/xul/base/src/nsBox.cpp:561 13 XUL nsBoxFrame::Reflow layout/xul/base/src/nsBoxFrame.cpp:758 14 XUL nsContainerFrame::ReflowChild layout/generic/nsContainerFrame.cpp:820 15 XUL ViewportFrame::Reflow layout/generic/nsViewportFrame.cpp:283 16 XUL PresShell::DoReflow layout/base/nsPresShell.cpp:6609 17 XUL PresShell::ProcessReflowCommands layout/base/nsPresShell.cpp:6714 18 XUL PresShell::DoFlushPendingNotifications layout/base/nsPresShell.cpp:4529 19 XUL PresShell::ReflowEvent::Run layout/base/nsPresShell.cpp:6491 20 XUL nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:510 21 XUL NS_ProcessPendingEvents_P nsThreadUtils.cpp:180 22 XUL nsBaseAppShell::NativeEventCallback widget/src/xpwidgets/nsBaseAppShell.cpp:121 23 XUL nsAppShell::ProcessGeckoEvents widget/src/cocoa/nsAppShell.mm:374
Version: 1.9.0 Branch → Trunk
(In reply to comment #23) > 2) Open url: https://litmus.mozilla.org/manage_testcases.cgi?testcase_id=5186 This gives me a login page. If possible, please provide a testcase that doesn't require a login. Anything interesting in the system console? Does my tryserver build from comment #16 fix the problem?
I tried today's branch nightly. This time, it crashed just trying to accessing a file dropdown from the Shiretoko menu. Tested on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090123 Shiretoko/3.1b3pre STR: 1) open shiretoko build 2) move mouse to upper left corner, click "shiretoko" in menu 3) Crash. Crash report: http://crash-stats.mozilla.com/report/index/342f3a37-70ab-4467-a61d-a5eca2090123 My MBP Console.log shows: 1/23/09 10:58:51 AM [0x0-0x207207].org.mozilla.firefox Fri Jan 23 10:58:51 TchungMBP.local firefox-bin[24068] <Warning>: CGSResolveShmemReference : reference offset (36128) exceeds bounds (32768) on shmem obj 0x21216 1/23/09 10:59:31 AM firefox-bin[24068] Mozilla has caught an Obj-C exception [NSInternalInconsistencyException: Error (1000) creating CGSWindow] 1/23/09 10:59:31 AM [0x0-0x207207].org.mozilla.firefox Fri Jan 23 10:59:31 TchungMBP.local firefox-bin[24068] <Warning>: CGSResolveShmemReference : reference offset (36016) exceeds bounds (32768) on shmem obj 0x21216 1/23/09 10:59:31 AM [0x0-0x207207].org.mozilla.firefox 2009-01-23 10:59:31.835 firefox-bin[24068:10b] Mozilla has caught an Obj-C exception [NSInternalInconsistencyException: Error (1000) creating CGSWindow] 1/23/09 10:59:57 AM [0x0-0x207207].org.mozilla.firefox Fri Jan 23 10:59:57 TchungMBP.local firefox-bin[24198] <Warning>: CGSResolveShmemReference : reference offset (36128) exceeds bounds (32768) on shmem obj 0x21216 1/23/09 11:00:00 AM [0x0-0x207207].org.mozilla.firefox Debugger() was called! 1/23/09 11:00:00 AM [0x0-0x207207].org.mozilla.firefox Debugger() was called!
(In reply to comment #25) Thanks for the info. But you still need to test with my tryserver build from comment #16.
> STR: > 1) open shiretoko build > 2) move mouse to upper left corner, click "shiretoko" in menu > 3) Crash. This doesn't work for me. I also tested with today's Shiretoko nightly.
Tony, do you have more than one monitor? The following suggests this might make "Error (1000) creating CGSWindow" more likely to appear: http://lists.apple.com/archives/xcode-users/2006/Oct/msg00131.html
nope, i am just using my laptop. now it's crashing repeatedly [@ nsIconChannel::MakeInputStream(nsIInputStream**, int)] on the branch nightly just by clicking your tryserver link. Sigh. http://crash-stats.mozilla.com/report/index/5eef4b3f-536d-4a38-8457-0851a2090123 I'll get your tryserver build up somehow, and get you more feedback.
Hey stephen, just fyi. I've been running your tryserver build for 2 days now, and there hasn't been a crash.
(In reply to comment #30) Glad to hear it, and thanks for letting us know. On Monday I'll post a new version of my patch with comments (but no code changes), and start the review process.
I was never able to recreate this at will, and I haven't seen this crash for a couple weeks now. I do sometimes have multiple monitors, but at least some of the crashes were on my laptop on its own.
(In reply to comment #32) > I haven't seen this crash for a couple weeks now Were you using one of my tryserver builds, or were you testing with nightlies?
(In reply to comment #33) > (In reply to comment #32) > > > I haven't seen this crash for a couple weeks now > > Were you using one of my tryserver builds, or were you testing with nightlies? I was using your tryserver build from comment 16, when no crashes happened. Ironically, i hopped back onto the trunk nightly yesterday (1/25), and hit this crash again. But again, to no reproducible avail. This was on nightly trunk build 20090124020525. http://crash-stats.mozilla.com/report/index/3851760b-41de-4f3d-be79-009782090125
Attached patch Fix/workaround — — Splinter Review
Here's my debugging patch with an explanatory comment. It'd be nice to know the ultimate cause(s) of the "Error (1000) creating CGSWindow" errors. But I don't think this is going to happen anytime soon. And there's no particular reason to think they're even specific to Firefox. My patch is a trivial workaround that can do no harm. And we now have sufficient evidence to think that it will do some good. We also know that nsObjCExceptionLogAbort crashes are a significant problem -- http://crash-stats.mozilla.com/ reports 11 nsObjCExceptionLogAbort crashes in nsCocoaWindow::Show() in the last hour.
Attachment #356023 - Attachment is obsolete: true
Attachment #358874 - Flags: review?(joshmoz)
> We also know that nsObjCExceptionLogAbort crashes are a significant > problem ... We also know that nsObjCExceptionLogAbort crashes *in nsCocoaWindow::Show()* are a significant problem ...
Please try my tryserver build from comment #16.
Comment on attachment 358874 [details] [diff] [review] Fix/workaround It isn't pretty, but OK. I can't wait until we have a better exception handling situation...
Attachment #358874 - Flags: review?(joshmoz) → review+
(In reply to comment #39) > It isn't pretty, but OK. I can't wait until we have a better exception handling > situation... Is there a bug on improving it?
We have no plans for improving it at the moment, not worth filing a bug until we have a good idea of what we'd do.
> better exception handling situation This underlying problem of this bug (and several others) is that the fix we adopted for bug 163260 doesn't allow us to handle non-fatal Objective-C exceptions except on an ad-hoc basis (as I've done here). This problem can only be "fixed" by getting rid of everything we did at bug 163260. That can only happen after we find a suitable replacement -- C++ exception handling?
Ultimately we need to make *all* Objective-C exceptions non-fatal (as they are in Safari and other "standard" Cocoa apps). But we need to find a way to do that that still prevents XPCOM from getting into a non-stable/unsafe state.
Lets not discuss replacement exception handling schemes in this bug.
Attachment #358874 - Flags: superreview?(roc)
Attachment #358874 - Flags: superreview?(roc) → superreview+
Landed on trunk: http://hg.mozilla.org/mozilla-central/rev/6218bf0bb692
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Comment on attachment 358874 [details] [diff] [review] Fix/workaround As I mentioned in comment #35, this patch has zero risk and (potentially) high reward. Now that the beta3 code freeze has been postponed, there's time for it to get into beta3. I think this should happen.
Attachment #358874 - Flags: approval1.9.1?
Is there anything extra that Tb3 will need to do to get the benefit of this patch? I'm actually getting these assert based crashes much more frequently on Shredder than I am on Minefield.
You won't see this patch in Shredder until it gets onto the 1.9.1 branch -- another reason to land this patch there.
I'm seeing compilation errors (attached) that go away if I locally revert the patch for this bug: http://hg.mozilla.org/mozilla-central/rev/6218bf0bb692 . I'll admit these errors are pretty bizarre. (I'm building debug on 10.4 / PPC, but still surprised nobody else is complaining. My build config has worked until now...)
(In reply to comment #49) I can build on a PPC machine running 10.4 ... though it takes many hours. Let me try a debug build with current trunk code and see what happens.
And by the way, what version of XCode do you have installed, and what does gcc_select return? I've got XCode 2.5 (on my PPC G4 running 10.4.11), and gcc_select returns "gcc version 4.0.1 (Apple Computer, Inc. build 5370)".
XCode 2.2.1, "gcc version 4.0.1 (Apple Computer, Inc. build 5250)"
I used XCode 2.2.1 for several years (usually with gcc 4.0.1), and had no trouble. I can't see how that's the cause ... but it still was worth asking. My debug build is progressing. In the meantime, I'm wondering if your problems are caused by corruption (in your .hg directories?), or possibly even hard disk trouble.
My debug build of current trunk code (on my PPC G4 running OS X 10.4.11) just finished without any trouble. For the record, I've attached what it logged while compiling nsCocoaWindow.mm. And here's my .mozconfig: . $topsrcdir/browser/config/mozconfig mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-firefox-debug mk_add_options MOZ_MAKE_FLAGS=-j4 mk_add_options AUTOCONF=/usr/local/oldauto/bin/autoconf ac_add_options --enable-application=browser ac_add_options --disable-optimize --enable-debug ac_add_options --enable-tests ac_add_options --enable-cpp-rtti ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.4u.sdk
Comment on attachment 358874 [details] [diff] [review] Fix/workaround Approving -- this is my #1 crash these days on the Mac!
Attachment #358874 - Flags: approval1.9.1? → approval1.9.1+
It wouldn't be unexpected to find some compiler differences/bugs/bugfixes along the way; jag and philor both have had issues building Camino, for instance, because they were still using downrev versions of Xcode 2.2.x (and whatever minor compiler revisions they contain), whereas Xcode 2.4.x handled the same code just fine. That said, the 10.4 ref platform [1] claims 2.2.1 is still the desired Xcode version (it also claims Darwin 8.7.x/8.8.x for OS versions, which I swear Sam told me had been changed to 8.10.x), so if this lands anywhere with 10.4 boxen that are actually using 2.2.1 like the refplatform states, those boxen will burn. For reference, there are 10.4 boxen on Firefox3.0 (1.9.0), SeaMonkey (1.9.1), and Thunderbird3.0 (1.9.1) (no idea what their Xcode versions are, though Thunderbird3.0 and SeaMonkey are green with this changeset). [1] https://wiki.mozilla.org/ReferencePlatforms/Mac
(In reply to comment #57) Before we draw any conclusions, I'd like to see someone else with XCode 2.2.1 try building the current tree (trunk and/or 1.9.1 branch). Take a look at my patch (including the code the macros expand to). I can't believe any unbroken version of gcc would choke on it.
Gcc on the Mac, that is (gcc that supports Objective-C syntax).
(In reply to comment #58) > (In reply to comment #57) > > Before we draw any conclusions, I'd like to see someone else with XCode 2.2.1 > try building the current tree (trunk and/or 1.9.1 branch). Yeah, sorry; I meant to preface the end of my second paragraph with a big "IF this is broken in 2.2.1, then those boxes..." (I'm under the weather today).
Crash Signature: [@nsObjCExceptionLogAbort] [@ nsCocoaWindow::Show]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: