Closed Bug 370954 Opened 17 years ago Closed 17 years ago

random crash [@ objc_msgSend_rtp][@ NSWindow sendEvent:][@ 0xfffeff20] when closing/changing tabs/windows

Categories

(Camino Graveyard :: General, defect)

1.8 Branch
PowerPC
macOS
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: alqahira, Unassigned)

References

()

Details

(Keywords: crash)

Crash Data

Attachments

(5 files)

There might be a couple of crashes in here; it's not clear yet.

Talkback has some crashes with these sigs where people are reporting closing/changing tabs/windows, and we're seeing some reports of it on the forum.  Talkback really doesn't give us anything useful in the way of stacks or comments, so it's hard to tell how many of the crashes it's flagging with these stacks are "this" crash.

I've also seen this a few times with the JVM in one of the other threads (but no Java applets currently open), but people on the forum report seeing this general tab/window close/change crash without the JVM in their other threads.

According to Talkback, these crashes suddenly (re)appear in the 207-02-07-22 build, which gives us http://tinyurl.com/3ar76j as a regression range.  The numbers have decreased some in the last few days, so we might be safe for b1.

(Since there's no trunk Talkback, have no idea if it's on trunk, too, or not).
Flags: camino1.1b1?
Flags: camino1.1?
If anyone can reproduce this somewhat quickly, it would be worth trying to repo under NSZombieEnabled=YES. I doubt it would be pleasant memory-wise to run that way for a really long time, but there's a good chance it would give us useful information.
Typical crash I've seen recently while having multiple tabs and windows open.  I believe Smokey has the regression dates close if not exact.
The crash logs aren't helpful, so we really need to see the zombies.
(In reply to comment #0)
> (Since there's no trunk Talkback, have no idea if it's on trunk, too, or not).
> 

FWIW, I haven't experience any kind of crash like this on Trunk, certainly not since the stated regression date.

FWIW, I'm hitting this many times a day since I started using a early-feb nightly. I just updated my nightly and will see if it remains unstable.
To cast the net a bit wider, if anyone who can repro this can run Camino with:
MallocScribble=1 MallocPreScribble=1 MallocGuardEdges=1
NSZombieEnabled=YES /Applications/Camino.app/Contents/MacOS/Camino
we could see if any of those catch something.
Kurt sent me the following (thanks Kurt!):
2007-02-21 03:51:06.133 Camino[319] *** Selector 'mouseEntered:' sent to dealloced instance 0x87a7c90 of class RolloverImageButton.
Break at '-[_NSZombie methodSignatureForSelector:]' to debug.
2007-02-21 03:51:06.140 Camino[319] *** Selector 'mouseEntered:' sent to dealloced instance 0x87a7c90 of class RolloverImageButton.
Break at '-[_NSZombie methodSignatureForSelector:]' to debug.
2007-02-21 03:51:06.917 Camino[319] *** Selector 'mouseExited:' sent to dealloced instance 0x87a7c90 of class RolloverImageButton.
Break at '-[_NSZombie methodSignatureForSelector:]' to debug.
2007-02-21 03:51:06.918 Camino[319] *** Selector 'mouseExited:' sent to dealloced instance 0x87a7c90 of class RolloverImageButton.
Break at '-[_NSZombie methodSignatureForSelector:]' to debug.
2007-02-21 03:51:07.151 Camino[319] *** Selector 'mouseEntered:' sent to dealloced instance 0x87a7c90 of class RolloverImageButton.
Break at '-[_NSZombie methodSignatureForSelector:]' to debug.
2007-02-21 03:51:07.152 Camino[319] *** Selector 'mouseEntered:' sent to dealloced instance 0x87a7c90 of class RolloverImageButton.
Break at '-[_NSZombie methodSignatureForSelector:]' to debug.
2007-02-21 03:51:07.233 Camino[319] *** Selector 'mouseExited:' sent to dealloced instance 0x87a7c90 of class RolloverImageButton.
Break at '-[_NSZombie methodSignatureForSelector:]' to debug.
2007-02-21 03:51:07.233 Camino[319] *** Selector 'mouseExited:' sent to dealloced instance 0x87a7c90 of class RolloverImageButton.
Break at '-[_NSZombie methodSignatureForSelector:]' to debug.

Given the regression range, that suggests it has to do with the popup blocker's close button, since that's the only thing that should have been affected by the change. I'll play around with that.
Had a really tiring day today; forgot to mention to Stuart the info in Comment #7 was from a trunk version of Camino, 2007021919 (1.2+) running under 10.4.8 with all current system, security, and Java updates.
Attached patch probable fixSplinter Review
I can't repro this still, but I see no reason to think this won't fix the problem, as the current code is clearly not doing the right thing.

I think the overall score now is something like Tracking Rects: 3, Camino: 0.
Attachment #255992 - Flags: superreview?(joshmoz)
Attachment #255992 - Flags: superreview?(joshmoz) → superreview+
Checked in. We'll keep this open and watch, but I think these will all go away (although it's tricky to know for sure, as there could be more than one cause here).
Are there any specific sites, or type of sites that are more prone to trigger these crashes ?
I've surfed around to my usual set of news sites and so on, multiple tabs, resing windows,... , with the logging stuff in comment 6 without triggering anything abnormal. Using Trunk, btw.

(Now building with the patch included. Faster than waiting for maya to spin a build)
No idea, having never repro'd it. If it was indeed exacerbated by fixing the button in the popup bar, then sites with popups would be candidates, but it could be timing specific. It's possible that this is sensitive to specific AppKit implementation details, so it could potentially be OS- or architecture-specific too.

We'll just have to wait and see if people seeing it a lot have a better time of it now, and if the talkback numbers settle down.
Sam just had a crash with "this stack" (see http://pastebin.mozilla.org/4097 ) that matches the circumstances in a few other Talkback comments for the general libobjc crash):

[12:14am] ss: Camino just crashed
[12:14am] ss: In the background
[12:14am] ss: With nothing major open
[12:14am] ss: A bunch of static websites and Gmail
[12:17am] ss: I'm using a (relatively) recent build even... Version 2007020922 (1.1a2+)

These might all be the same user, though (given the comments and the 10.3.9): TB29493297x, TB29469148x, TB29370936x
Debug Command:
MallocScribble=1 MallocPreScribble=1 MallocGuardEdges=1 NSZombieEnabled=YES /Applications/Camino.app/Contents/MacOS/Camino
The crash from comments 14 and 15 are completely unrelated to this bug (and  indicate a system problem unrelated to Camino).
(In reply to comment #13)
> These might all be the same user, though (given the comments and the 10.3.9):
> TB29493297x, TB29469148x, TB29370936x

These are indeed the "same user", and it's me. I switched back to 1.0.3 yesterday, but if there's something I can do to help with this, let me know. I do have system.log's and Camino.crash.log's from right after all 3 crashes.


(In reply to comment #17)
> if there's something I can do to help with this, let me know.

The best thing would be to try today's build and see if you still have crashes, and if so, trying to reproduce them using the command from comment 6.
I installed the 2/22 build and got another background crash <a href="http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=29596829">29596829</a> under same circumstances -- while I was editing scripts in Supercard. 

I'm afraid I don't know how to use the command from comment 6. Is that something I would enter into Terminal?
(In reply to comment #19)
> I installed the 2/22 build and got another background crash

Could you post the crash log? Talkback isn't giving enough information to even begin to guess if it's the same problem.

> Is that something I would enter into Terminal?

Yes, assuming you have Camino in your /Applications folder, you should just be able to run that command as-is (although make sure you remove the line break that bugzilla put in the middle of the line; it should all be one line).

Drat. Definitely do try to run with the comment 6 command then, and post any crash logs you get that way, as well as any output you see in Terminal that resembles comment 7
I spent another 4 or 5 hours in Supercard with Camino (2/22 nightly) in background, run with the comment 6 command, and no crash.

Don't know if it's relevant but I get the following in Terminal when I run Camino with the comment 6 command: /Applications/Camino.app/Contents/MacOS/Camino: can't map file: /Library/Internet Plug-Ins/Flash Player Enabler.plugin ((os/kern) invalid argument)
 
And no mention of NSZombie in the Terminal output? It would likely prevent it from actually crashing.
[12:20am] ss: Camino just crashed again
[12:20am] ss: In the background.
[12:21am] ss: I was using Version 2007022122 (1.1a2+)
[12:21am] ss: But it should have been fixed by then.
[12:22am] ardissone|mowing: smorgan checked in that fix on 2-21 19:01
[12:22am] ardissone|mowing: so it should have been in your build

The background crash must be something different, then :(
Flags: camino1.1b1? → camino1.1b1-
I've been using the comment 6 command with the 2/24 nightly and no crashes, no mention of NSZombie in the terminal output or anything that resembles comment 7. Just what I mentioned about Flash in comment 23 and also this:

2007-02-26 16:05:10.990 Camino[1927] *** -[NSCFString characterAtIndex:]: Range or index out of bounds

I assume from comment 25 you've determined that what I've got going on is not related to this bug anyway? So should I resume running Camino normally? Do you want more crash reports if they continue to happen? 
(In reply to comment #26)
> 2007-02-26 16:05:10.990 Camino[1927] *** -[NSCFString characterAtIndex:]: Range
> or index out of bounds

Well that certainly isn't good, but wouldn't be related to the crash. (I'll spin out a new bug to fix some possible causes.)

> I assume from comment 25 you've determined that what I've got going on is not
> related to this bug anyway? So should I resume running Camino normally? Do you
> want more crash reports if they continue to happen?

Smokey just meant that there must be at least one other cause of crashes that look like this other than what Kurt found. If you are willing to keep running that way and looking for zombies or crashes (which aren't helpful raw, but may be a bit more useful when they happen under the commands in comment 6), it would be great.
I might have a fix for this at bug 372003 (though not yet an actual
patch).
> If you are willing to keep running
> that way and looking for zombies or crashes (which aren't helpful raw, but may
> be a bit more useful when they happen under the commands in comment 6), it
> would be great.

Okay, I'll report any odd terminal output here.

A patch based on Steven's report was just checked in, so anyone who was seeing this should try to reproduce on tomorrow's build and see if they can still reproduce it.
(In reply to comment #30)
> A patch based on Steven's report was just checked in, so anyone who was seeing
> this should try to reproduce on tomorrow's build and see if they can still
> reproduce it.

Today's (2007-03-06) build is in fact the first one in which I can no longer reproduce the crash.  I had a set of sure-fire steps that reliably fell victim to it every single time.  The crash had occurred on builds up to and including the previous night's (2007-03-05).

(In reply to comment #4)
> FWIW, I haven't experience any kind of crash like this on Trunk, certainly not
> since the stated regression date.

For me, the crashing had been occurring in both trunk and 1.1 builds, up until today.
Based on Talkback investigation and reports from murph and others, calling this one FIXED by bug 372003.  Thanks all!
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Flags: camino1.1? → camino1.1+
Crash Signature: [@ objc_msgSend_rtp] [@ NSWindow sendEvent:] [@ 0xfffeff20]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: