Closed Bug 414574 Opened 13 years ago Closed 13 years ago

crashes when closing tab using "x" button or middle click

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: u294409, Unassigned)

References

Details

(Keywords: crash, regression) 

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9b3pre) Gecko/2008012904 Fedora/8 (Werewolf) Minefield/3.0b3pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9b3pre) Gecko/2008012904 Fedora/8 (Werewolf) Minefield/3.0b3pre

firefox crashes when closing tabs.
problem appeared in 2008012904.
in older than 2008012904 I had no problems with firefox.

Reproducible: Always

Steps to Reproduce:
1. close a tab
Actual Results:  
firefox crashes and doesn't show crash reporter

Expected Results:  
no crashes :D (kidding) !!!
I can confirm this bug.

Seeing it with an homemade trunk build (tagged as Gecko/2008012914), on my archlinux 64 bits. Have to downgrade to a 28 hours old build to close tabs without crash ! :(
Severity: critical → blocker
Status: UNCONFIRMED → NEW
Ever confirmed: true
Guilty checkins could be :

* bug 398627 
* bug 405693 
* bug 414489
* bug 414203 => this one smells to be the right one ?!

Just looking at checkins between 28th January 2008 04:00 mozilla.org time to 29th January 2008 04:00 mozilla.org time.
Anyone have a brakepad id for this crash?
Flags: blocking-firefox3?
Keywords: crash
I have no breakpad for today. Firefox just crashed without "bye bye".
I had the same issue starting with today's nightly. Disabling the RealPlayer Browser Record Plugin 1.0 in the extension list stopped the crashing when closing tab using "x" button or middle click.

I have no RealPlayer, but I'll try to disable Flash and Totem.
Did not helped me. Not a plugin issue at all.
Extensions, perhaps? Does it happen in Safe mode?
So, no extensions here.
Adblock Plus, Adblock Plus Filterset.G Updater, NoScript.

Something in Firefox' code was made, becase in previous nightly everything worked well. It cannot be plugins or extensions issue...
(In reply to comment #10)
> Something in Firefox' code was made, becase in previous nightly everything
> worked well. It cannot be plugins or extensions issue..

The fact that it worked before doesn't mean it's unrelated to extensions. A patch that landed might have caused extension code to break, and finding out whether that's the case is valuable. Can you reproduce the crash in safe mode?
How to run Minefield in safe mode on Linux if it does not provide any .desktop files :> ?

Should I supply some option after ./firefox script?
./firefox -safe-mode or something like this.

Gavin : OK. But how do you explain I see this bug WITHOUT ANY EXTENSIONS added ?

In comment #2, I listed some bugs which can be guilty. How about reversing some patches ?

I don't have time right now, but until culprit is found, I won't build any firefox from trunk code. First time for at least 6 months or so.

And I'm using trunk code since end of 2000...
 $ ./firefox -safe-mode
./run-mozilla.sh: line 131:  6459 Naruszenie ochrony pamięci   "$prog" ${1+"$@"}
 $ 
(In reply to comment #7)
> Did not helped me. Not a plugin issue at all.
> 

Sorry 'bout that.  Worked for me.  Strange. If I enable the RealPlayer
Browser Record Plugin 1.0 extension, I get an immediate crash when attempting to close a tab using the 'X'

Perhaps it's related in some way. Maybe I need to file a separate bug?
Still crashes with disabled extensions and others.
Do you believe me now?
@Dave: RealPlayer is old. You can always file some bug (if any bugtracker available) in Helix bugzilla. They probably need to change some code.
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b3pre) Gecko/2008012904 Minefield/3.0b3pre

Crashes on closing tab when using a new profile with all plugins disabled. Also crashes in safe mode.

Breakpad Ids
bf2fe97a-ce8f-11dc-9ce5-001a4bd43ef6
e93001b0-ce8f-11dc-b692-001a4bd43ed6
d1d3c970-ce9b-11dc-9c08-001a4bd43ef6
9e281f17-ce9d-11dc-985b-001a4bd43ef6
(In reply to comment #13)
> Gavin : OK. But how do you explain I see this bug WITHOUT ANY EXTENSIONS added?

Sorry, I missed your comment. Does this bug only occur on 64bit Linux?
Can someone who can reproduce use builds from http://hourly-archive.localgho.st/linux.html to find a minimal regression range?
If crashes on Windows too, marking as OS: All.
OS: Linux → All
Gavin : I don't know about 32 bits based linux :)

I have a 32 bit virtualized OpenSuSE 10.3

Will try with your URL.

Let's hope we will find a good range ;)
32bit in here. Fedora/8.
Results of regression range testing:
20080128_2005_firefox-3.0b3pre.en-US.win32.zip - no crash
20080128_2043_firefox-3.0b3pre.en-US.win32.zip - crash

http://hourly-archive.localgho.st/win32/20080128_2043_checkins.html
Now some experienced developer must investigate, what patch made as mess...

Thanks, Tony, for testing. Your work and time you've used to find regression will be very appreciated :) .
(In reply to comment #24)
> Results of regression range testing:
> 20080128_2005_firefox-3.0b3pre.en-US.win32.zip - no crash
> 20080128_2043_firefox-3.0b3pre.en-US.win32.zip - crash
> 
> http://hourly-archive.localgho.st/win32/20080128_2043_checkins.html

Offhand I'm not sure which of those is most likely... I'm not sure whether the accessibility one would affect "normal" builds.
Keywords: regression
> I'm not sure whether the accessibility one would affect "normal" builds.

On Linux, it easily could.  Dunno about the other OSes.

In any case, the very first talkback incident in comment 18 shows an infinite recursion in accessibility that blows out the stack:

12  	nsDocAccessible::RemoveEventListeners()  	 mozilla/accessible/src/base/nsDocAccessible.cpp:700
13 	nsDocAccessible::Shutdown() 	mozilla/accessible/src/base/nsDocAccessible.cpp:533
14 	nsAccessNode::GetPresShell() 	mozilla/accessible/src/base/nsAccessNode.cpp:339
15 	nsDocAccessible::RemoveEventListeners() 	mozilla/accessible/src/base/nsDocAccessible.cpp:700

etc.  My money is on bug 405951.  ccing Daniel just in case it's actually the other bug, somehow.
Blocks: 405951
Ah, this should be fixed already because of the last patch I checked in, which makes RemoveEventListeners() take a pres shell instead of a doc.
Never mind, the opposite is true. That caused it. Patch coming up.
I put a patch for review in the original bug that caused it - bug 405951.
Fixed via checkin in bug 405951.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Flags: blocking-firefox3? → blocking-firefox3+
Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9) Gecko/2008051202 Firefox/3.0

Works oK on RC1


Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9) Gecko/2008052903 Firefox/3.0

Works on RC2
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9) Gecko/2008053008 Firefox/3.0

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008060309 Firefox/3.0

Works on RC2

Marked "verified". No activity for 4 months shows it too :)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.