431454 - Crash on startup [nsWebBrowser::BindListener(nsISupports*, nsID const&)]

Status: RESOLVED DUPLICATE of bug 308245

(Core Graveyard :: Embedding: GRE Core, defect)

Description

[philippe (part-time)]

Attachment: crash log

Click on dock icon to launch browser, browser crashes (repeatedly).
Moving the profile folder aside allows life to continue.

I narrowed it down to the compreg.dat file.


0   org.mozilla.camino            	0x00632155 nsWebBrowser::BindListener(nsISupports*, nsID const&) + 359
1   org.mozilla.camino            	0x00631271 nsWebBrowser::Create() + 373
2   org.mozilla.camino            	0x00027615 -[CHBrowserView initWithFrame:] + 441
3   org.mozilla.camino            	0x00002f5e -[BrowserWrapper initWithFrame:inWindow:] + 226
4   org.mozilla.camino            	0x00002e68 -[BrowserWrapper initWithTab:inWindow:] + 80
5   org.mozilla.camino            	0x00014d76 -[BrowserWindowController createNewTabItem] + 102
6   org.mozilla.camino            	0x00013ac0 -[BrowserWindowController createNewTab:] + 32
7   org.mozilla.camino            	0x0001bfca -[BrowserWindowController windowDidLoad] + 1230
8   com.apple.AppKit              	0x9092770a -[NSWindowController _windowDidLoad] + 525
9   com.apple.AppKit              	0x908c56f4 -[NSWindowController window] + 126
10  com.apple.AppKit              	0x908c55f4 -[NSWindowController showWindow:] + 45

Comment 1

[philippe (part-time)]

Attachment: the offending compreg.dat file (zipped)

Note that the same compreg.dat file doesn't crash in my own profile (but using trunk).

Comment 2

[Chris Lawson (gone)]

Can you get Minefield (or Firefox 2) to crash with this compreg.dat file? Seems like that's Core code that we wouldn't be doing anything special with.

Comment 3

[philippe (part-time)]

(In reply to comment #2)
> Can you get Minefield (or Firefox 2) to crash with this compreg.dat file? Seems
> like that's Core code that we wouldn't be doing anything special with.
> 

Minefield has no problems.
Firefox 2.0.0.14 crashes right away - after selecting my Fx2 profile in the profile manager, it goes just poof, bye. No crashlog, Talkback or whatever.

Comment 4

[Chris Lawson (gone)]

I'm gonna kick this to Core:Embedding since that's where other nsWebBrowser stuff seems to live and cc bz while I'm at it.

Comment 5

[Chris Lawson (gone)]

bz, does this look at all like bug 308245 to you?

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Not sure if it is relevant or not, but what app+branch was used to create this compreg.dat (or last touched it prior to this crash incident)?

Comment 7

[philippe (part-time)]

(In reply to comment #6)
> Not sure if it is relevant or not, but what app+branch was used to create this
> compreg.dat (or last touched it prior to this crash incident)?

That was with Camino 1.6 running on 10.5.2 Intel. The user profile has never been used for anything but Camino 1.5.x and newer.
Shouldn't have been touched by anything else.

Comment 8

[Chris Lawson (gone)]

Philippe, I'd be kind of curious to know what happens if you open that compreg.dat file in a text editor and remove (one at a time) line 1051, line 1052, and line 1053.

Comment 9

[Chris Lawson (gone)]

By the way, those lines are:

@mozilla.org/intl/unicode/decoder;1?charset=x-mac-devanagari,{6803cac4-1e3b-11d5-a145-005004832142}
@mozilla.org/embedding/browser/nsWebBrowser;1,{f1eac761-87e9-11d3-af80-00a024ffc08c}
@mozilla.org/intl/unicode/decoder;1?charset=Shift_JIS,{0e6892c1-a9ad-11d2-b3ae-00805f8a6670}

The one I'm most interested in is the nsWebBrowser line.

Comment 10

[Chris Lawson (gone)]

Further investigation reveals that the function where this is crashing is identical on branch and trunk:

Branch: http://mxr.mozilla.org/mozilla1.8/source/embedding/browser/webBrowser/nsWebBrowser.cpp#273
Trunk: http://mxr.mozilla.org/mozilla/source/embedding/browser/webBrowser/nsWebBrowser.cpp#263

Comment 11

[Chris Lawson (gone)]

Huh. When I remove line 1052 and line 331 (the line containing the associated contract ID from line 1052), I get this crash instead:

Process:         Camino [69325]
Path:            /Applications/Internet/Camino Official Nightlies/Branch/Camino.app/Contents/MacOS/Camino
Identifier:      org.mozilla.camino
Version:         1.6.1pre (1608.04.29)
Code Type:       PPC (Native)
Parent Process:  launchd [75]

Date/Time:       2008-04-30 01:24:44.970 -0400
OS Version:      Mac OS X 10.5.2 (9C7010)
Report Version:  6

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000
Crashed Thread:  0

Thread 0 Crashed:
0   org.mozilla.camino            	0x00029e30 -[CHBrowserView initWithFrame:] + 272
1   org.mozilla.camino            	0x00004730 -[BrowserWrapper initWithFrame:inWindow:] + 288
2   org.mozilla.camino            	0x000045dc -[BrowserWrapper initWithTab:inWindow:] + 92
3   org.mozilla.camino            	0x00017790 -[BrowserWindowController createNewTabItem] + 128
4   org.mozilla.camino            	0x000162e0 -[BrowserWindowController createNewTab:] + 48
5   org.mozilla.camino            	0x0001ea44 -[BrowserWindowController windowDidLoad] + 1892
6   com.apple.AppKit              	0x92ec7834 -[NSWindowController _windowDidLoad] + 448
7   com.apple.AppKit              	0x92e6fe44 -[NSWindowController window] + 120
8   com.apple.AppKit              	0x92e6fd28 -[NSWindowController showWindow:] + 32
9   org.mozilla.camino            	0x0000a48c -[MainController openBrowserWindowWithURL:andReferrer:behind:allowPopups:] + 204
10  org.mozilla.camino            	0x0000b4cc -[MainController newWindow:] + 220
11  org.mozilla.camino            	0x00008a88 -[MainController applicationDidFinishLaunching:] + 120
12  com.apple.Foundation          	0x919f0ea4 _nsnote_callback + 372
13  com.apple.CoreFoundation      	0x9554c95c _CFXNotificationPostNotification + 920
14  com.apple.Foundation          	0x919ee6d8 -[NSNotificationCenter postNotificationName:object:userInfo:] + 88
15  com.apple.AppKit              	0x92ee5a00 -[NSApplication _postDidFinishNotification] + 108
16  com.apple.AppKit              	0x92ee5918 -[NSApplication _sendFinishLaunchingNotification] + 80
17  com.apple.AppKit              	0x92e6d218 -[NSApplication(NSAppleEventHandling) _handleAEOpen:] + 260
18  com.apple.AppKit              	0x92e6ca50 -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] + 88
19  com.apple.Foundation          	0x91a116fc -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 480
20  com.apple.Foundation          	0x91a114d0 _NSAppleEventManagerGenericHandler + 236
21  com.apple.AE                  	0x93a80ce0 aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned long, unsigned char*) + 164
22  com.apple.AE                  	0x93a80be8 dispatchEventAndSendReply(AEDesc const*, AEDesc*) + 40
23  com.apple.AE                  	0x93a809ec aeProcessAppleEvent + 212
24  com.apple.HIToolbox           	0x91105e84 AEProcessAppleEvent + 52
25  com.apple.AppKit              	0x92e6a5f4 _DPSNextEvent + 1148
26  com.apple.AppKit              	0x92e69d84 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 112
27  com.apple.AppKit              	0x92e63a40 -[NSApplication run] + 736
28  com.apple.AppKit              	0x92e34444 NSApplicationMain + 440
29  org.mozilla.camino            	0x0000455c main + 236
30  org.mozilla.camino            	0x00003038 _start + 756
31  org.mozilla.camino            	0x00002d3c start + 44

which fingers

http://mxr.mozilla.org/mozilla/source/camino/src/embedding/CHBrowserView.mm#213

which is just upstream of where the previous crash was. I'd hazard a guess that line 217 or 226 is failing, because it looks to me like lots of bad things could happen if |browser| is a garbage value.

Comment 12

[philippe (part-time)]

(In reply to comment #8)

Crash, boom :-).
I created a new profile with Cm 1.6, swapped in the corrupt compreg.dat, then deleted one line at the time. Each time the browser goes down.

And I get the same as comment 11.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Making it impossible to instantiate an nsWebBrowser will just guarantee that things don't work.

For the original crash, can you get me a line number?  Or better yet general debugger info?  A breakpad incident id?

Those byte offsets are only so useful...

Comment 14

[Chris Lawson (gone)]

Philippe, if you've got a branch tree, you might try the patch over in the other bug and see if that fixes it. I don't have one or else I'd try it myself and see what I could do about getting some answers to comment 13 :-\

I will say that when I reproduced the original crash, Talkback never fired, so I doubt there's any Talkback or Breakpad info to be had here.

I'll see what I can do about attaching a debugger to a release build later and try to come up with some more useful information.

Comment 15

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

It's possible that someone has hit this bug again in 2.0b2 (first a crash, then 2 successive startup crashes); see TB53984300x, TB53984391x and TB53984408x.

Comment 16

[timeless]

so i've decided that bug 308245 is really the fix for this crash. The problem (and we hit it with our embedding too) is of course that the contract doesn't map to anything so SetDocShell flows to the null case where it does nothing and returns NS_OK and then the assert doesn't hold.

very sorry for not pushing. please do push to make sure the fix visits a tree.