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

RESOLVED FIXED

Status

()

Core
Widget: Cocoa
P1
critical
RESOLVED FIXED
9 years ago
7 years ago

People

(Reporter: dveditz, Assigned: smichaud)

Tracking

({crash, fixed1.9.1})

Trunk
x86
Mac OS X
crash, fixed1.9.1
Points:
---
Bug Flags:
blocking1.9.1 -
wanted1.9.1 +

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

9 years ago
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
(Reporter)

Comment 1

9 years ago
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]
(Reporter)

Comment 4

9 years ago
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)

Updated

9 years ago
Assignee: joshmoz → smichaud
Priority: -- → P1

Comment 5

9 years ago
dveditz - can you reproduce this at will? Can you reproduce it without any extensions enabled?

Can anyone besides dveditz reproduce this at will?
(Assignee)

Comment 6

9 years ago
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
(Assignee)

Comment 7

9 years ago
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.
(Assignee)

Comment 8

9 years ago
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.
(Assignee)

Comment 9

9 years ago
Created attachment 356023 [details] [diff] [review]
Patch for debugging

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.

Comment 10

9 years ago
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-

Comment 11

9 years ago
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?

Comment 13

9 years ago
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.

Comment 17

9 years ago
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.

Comment 20

9 years ago
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.

Comment 22

9 years ago
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

Updated

9 years ago
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.
(Reporter)

Comment 32

9 years ago
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
Created attachment 358874 [details] [diff] [review]
Fix/workaround

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 ...
I've been hitting this type of crash a lot lately in both Minefield and Shredder.  Very intermittent, but frequent.  I usually restart and then do the exact same action (clicking, keyboard shortcut, whatever) that triggered the crash and it goes through fine.

My Minefield crashes today:
http://crash-stats.mozilla.com/report/index/c192eb5d-1146-4330-be47-66d872090126
http://crash-stats.mozilla.com/report/index/ce6f23c5-c0c0-482f-be5c-e9f852090126

My Shredder crashes today:
http://crash-stats.mozilla.com/report/index/ce6f23c5-c0c0-482f-be5c-e9f852090126
http://crash-stats.mozilla.com/report/index/67d782a2-d66d-4e1b-84a5-a44d72090126
http://crash-stats.mozilla.com/report/index/32c788b2-2c76-4ac0-969a-70c152090126
http://crash-stats.mozilla.com/report/index/51c4702f-c9a6-4182-b2d9-af7562090126
http://crash-stats.mozilla.com/report/index/0f418d91-5ace-4fc1-b8db-9d0842090126
Please try my tryserver build from comment #16.

Comment 39

9 years ago
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?

Comment 41

9 years ago
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.

Comment 44

9 years ago
Lets not discuss replacement exception handling schemes in this bug.
(Assignee)

Updated

9 years ago
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
Last Resolved: 9 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.
Created attachment 360863 [details]
compilation errors resulting from this patch

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.
Created attachment 360949 [details]
Log of compiling nsCocoaWindow.mm (showing no errors)

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+
Landed on the 1.9.1 branch:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/f12591191187
Keywords: fixed1.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.