373700 - Crash on startup [@ 0xfffeff20][@ libobjc.a.dylib.227.0.0]

Status: VERIFIED INVALID

(Camino Graveyard :: General, defect)

Description

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

Talkback is showing some crashes (often at startup) with these fun stacks.  They seem to appear between the 2007-03-06 01:00 and 22:00 builds (although there might have been some lost among the tracking-rect crashes; I haven't checked back more than one day in the tracking-rect madness).

Some TB queries that bring up incidents for this: 
http://talkback-public.mozilla.org/search/start.jsp?search=1&searchby=stacksig&match=contains&searchfor=0xfffeff20&vendor=MozillaOrg&product=Camino11&platform=MacOSX&buildid=2007030922&sdate=&stime=&edate=&etime=&sortby=bbid&rlimit=500
http://talkback-public.mozilla.org/search/start.jsp?search=1&searchby=stacksig&match=contains&searchfor=0xfffeff20&vendor=MozillaOrg&product=Camino11&platform=MacOSX&buildid=2007030622&sdate=&stime=&edate=&etime=&sortby=bbid&rlimit=500
http://talkback-public.mozilla.org/search/start.jsp?search=1&searchby=stacksig&match=contains&searchfor=libobjc.A.dylib.227.0.0&vendor=MozillaOrg&product=Camino11&platform=MacOSX&buildid=2007030622&sdate=&stime=&edate=&etime=&sortby=bbid&rlimit=500

Comment 1

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

Since you can't have talkback only find crashes in builds from a certain range, the next best (worst) thing is to run the query only for crashes occurring after said date, and sort by build, so you can scan downwards until you see the last valid build ID (MozillaOrgCamino11MacOSX2007030622).

http://talkback-public.mozilla.org/search/start.jsp?search=1&searchby=stacksig&match=contains&searchfor=libobjc.A.dylib.227.0.0+&vendor=MozillaOrg&product=Camino11&platform=MacOSX&buildid=&sdate=03%2F06%2F2007&stime=22%3A00%3A00&edate=04%2F01%2F2007&etime=00%3A00%3A00&sortby=build&rlimit=500
http://talkback-public.mozilla.org/search/start.jsp?search=1&searchby=stacksig&match=contains&searchfor=0xfffeff20+&vendor=MozillaOrg&product=Camino11&platform=MacOSX&buildid=&sdate=03%2F06%2F2007&stime=22%3A00%3A00&edate=04%2F01%2F2007&etime=00%3A00%3A00&sortby=build&rlimit=500

So far we have 27 crashes with these stacks (which is about equal to, or more than, the tracking rects crash in pre-1.1b builds), though not every one of the 27 is really this crash, I don't think.  This might be shaping up to be another bad crash :(

Comment 2

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

There's also a (new on the 20th) crash around startup at 0xfffeff18 (see TB30428717x for it) which looks similar at the bottom but may well be entirely dfferent.

Comment 3

[Antonio Moreno]

Attachment: froodian asked me for the crash log of camino from 03-13-07

my computer is one powerbook g4 alu 1ghz 2gb ram 64mb video ram. when i installed the nightly build i left installed all the camino extras i had in the 1.0.3 int. version:more camino, camino growl camino session , unify camino, camino agent and the program 1passwd.

Comment 4

[Samuel Sidler (old account; do not CC)]

The log also notes that he had APE and Inquisitor installed. I'm not sure what version of Inquisitor (only one version actually works with Camino, the rest are Safari-only), but any one of these haxies could have been involved in the crash.

Comment 5

[Stuart Morgan]

CaminoGrowl, CaminoSession, UnifyCamino, 1passwd, APE, and Inquisitor all have the potential to cause arbitrary problems with Camino. Crash logs with
haxies installed are not useful.

Comment 6

[Samuel Sidler (old account; do not CC)]

Unfortunately for us, this is one of our more major crashes and is happening all the time. If haxies are involved with these crashes (which is more likely than not), is there anything we can do to prevent them?

In the actual log itself, APE only shows once and none of the other haxies do at all. I know that doesn't mean they weren't involved in the crash, but there's potential that they weren't at least.

We need to look and see if there's anything on our end even if the only reports that come in have haxies installed. At worst, we should see what the common haxie is that's causing the problem and warn our users.

Comment 7

[Stuart Morgan]

There's no useful symbol information in the startup crash, so there's really nothing useful we can get out of it anyway.

Is this (and by "this" I mean crashing on startup, as opposed to the occurrence of a very common objc address at the top of the stack) really that common?

Comment 8

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

Stacks looking similar-ish to the ones I originally pulled out of Talkback are happening at about 1-2 a day, which is just slightly lower than what the tracking rects crash was running before Beta.  Most of the incidents aren't annotated, so we can't tell if they're all "crash at startup" or not, and of the good stacks I found, only a two had emails.

I'd love to believe these are all 1passwd crashes, but I don't think they are; when I asked about crashes at startup on the forum, the only response I got was 1passwd, but with a very different stack/crashed thread: http://forums.mozillazine.org/viewtopic.php?p=2797870#2797870

Comment 9

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

Attachment: Talkback incidents from comment 0

For record-keeping, Talkback incidents from comment 0.  The interesting/scary ones are the first few.

Comment 10

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

I did still see a couple of recent builds with the stacks like comment 0/comment 9 in my latest pass through Talkback, but not in the volume I saw when filing this bug.

I'd like to keep this 1.5? until we get feedback/Talkback from the bug-complete RC (or decide not to do one)....

Comment 11

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

Mostly for my convenience, queries for "these crashes" for April:

http://talkback-public.mozilla.org/search/start.jsp?search=1&searchby=stacksig&match=contains&searchfor=libobjc.A.dylib.227.0.0+&vendor=MozillaOrg&product=Camino11&platform=MacOSX&buildid=&sdate=04%2F01%2F2007&stime=22%3A00%3A00&edate=04%2F30%2F2007&etime=00%3A00%3A00&sortby=build&rlimit=500
http://talkback-public.mozilla.org/search/start.jsp?search=1&searchby=stacksig&match=contains&searchfor=0xfffeff20+&vendor=MozillaOrg&product=Camino11&platform=MacOSX&buildid=&sdate=04%2F01%2F2007&stime=22%3A00%3A00&edate=04%2F30%2F2007&etime=00%3A00%3A00&sortby=build&rlimit=500

Comment 12

[Sean Murphy]

One common element on top of the most recent talkback stack traces is: 

-[BrowserWindowController createNewTabItem]() [/builds/tinderbox/Cm1.1-M1.8/Darwin_8.6.0_Depend/build/ppc/camino//builds/tinderbox/Cm1.1-M1.8/Darwin_8.6.0_Depend/build/ppc/camino/src/browser/BrowserWindowController.mm, line 3795]

http://mxr.mozilla.org/mozilla1.8/source/camino/src/browser/BrowserWindowController.mm#3795

Any credence to suspect a problem among this method?

Comment 13

[Sean Murphy]

I tried out various code-injection and method-swizzling InputManger "plugins" in an attempt to cause this crash, since if there was a problem among our code, chances are we would see this even more often and also run into it ourselves once and a while.

I'm now willing to bet that much of this problem stems entirely from 1Passwd.  With 1Passwd as my only third-party extension installed, I am able to reproduce the crash at launch time and match up my stack trace with many from the latest talkback reports:

> #0  objc_msgSend + 8
> #1  -[BrowserWindowController createNewTabItem] + 297 (BrowserWindowController.mm:3790)
> #2  -[BrowserWindowController createNewTab:] + 42 (BrowserWindowController.mm:3423)
> #3  -[BrowserWindowController windowDidLoad] + 3206 (BrowserWindowController.mm:987)
> #4  -[NSWindowController _windowDidLoad] + 376
> #5  -[NSWindowController window] + 121
> #6  -[NSWindowController showWindow:] + 38
> #7  -[MainController openBrowserWindowWithURL:andReferrer:behind:allowPopups:] + 280 (MainController.mm:635)
> #8  -[MainController newWindow:] + 323 (MainController.mm:1010)
> #9  -[MainController applicationDidFinishLaunching:] + 114 (MainController.mm:337)

and with a release build, sometimes just:
> #0  0x90a59378 in objc_msgSend ()
> #1  0x00014814 in start ()

1Passwd works by installing a SIMBL bundle for each Cocoa-based browser it supports.  It forces a new toolbar item into our browser window, which is probably where the problem occurs.

I can't prove that all of these launch crashes are caused by 1Passwd, but I think it plays a major role, more so than we originally thought in comment 8.  Unlike the forum post linked in that comment, my 1Passwd-caused-crash stack trace was consistent with the talkback reports.

Comment 14

[Stuart Morgan]

Closing as invalid based on comment 13; thanks for looking into that.

I've emailed 1passwd and asked them to do strict version checking, since the current situation sucks. For 1.5 we may have to consider checking for 1passwd at startup (at least after a crash) and telling users to remove it. I'd hate to go that route, but I'd like to actually know if we have crashers of our own in 1.5.