506892 - crash if I close the tab after any page of arsenal.com has been open for a few minutes

Status: RESOLVED INCOMPLETE

(Firefox :: General, defect)

Description

[Christopher May]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.1.1) Gecko/20090727 Gentoo Shiretoko/3.5.1
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.1.1) Gecko/20090727 Gentoo Shiretoko/3.5.1

Been happening for several versions now. Basically when you have left a tab on arsenal.com for a few minutes (I have tried to time it, its normally more then 5) and you close the tab or move away from the page you get a seg fault.

Reproducible: Sometimes

Steps to Reproduce:
1.goto www.arsenal.com
2.leave for a few minutes
3.navigate away from page
Actual Results:  
Seg fault

Expected Results:  
as normal, move away from page without seg faulting

I believe it is flash related, I'll test more on that later. It only happens on that website though, other flash sites are unaffected. Flash version 10.0.22.87.

Selecting Critical due to the fact the software crashes. It's not the end of the world with this bug, but very very annoying.

Comment 1

[u348128]

Can you provide the crash id's?

Go to 'about:crashes'.

But the id in this bug and prefix it with 'bp-'. In this way it becomes clickable.

Comment 2

[Christopher May]

It says the url is invalid. No crash submit option came up when I restarted Firefox mind you so there wasn't an option to send one.

www-client/mozilla-firefox-3.5.1  USE="dbus iceweasel java -bindist -custom-optimization -gnome -mozdevelop -restrict-javascript -startup-notification" LINGUAS="en_GB"

Just in case it's Gentoo related.

Comment 3

[timeless]

please follow your distribution's bug reporting guidelines:

http://www.gentoo.org/doc/en/bugzilla-howto.xml

Comment 4

[Marien Zwart]

From the page timeless linked to specifically you want to apply the "Debugging using GDB" section to the net-libs/xulrunner package. I would do roughly this:

- Rebuild xulrunner with splitdebug in FEATURES and -ggdb in CFLAGS and CXXFLAGS (temporarily edit make.conf or set them on the commandline if you know what you're doing)
- (re)start Firefox
- Attach gdb, using "gdb -p $(pidof firefox)" (or look up the pid through other means and use "gdb -p thatpid"
- Wait for gdb to initialize and enter "c" to continue
- Crash firefox
- Enter "bt full" on the gdb prompt
- Attach your gdb output here

You can use nostrip instead of splitdebug in FEATURES if you prefer (with splitdebug debug info is stored separately, so cannot affect load times and the like while you're not debugging).

Note that "gdb --args /usr/bin/firefox" will not work: that's a wrapper script. Since you're not crashing on startup attaching gdb after starting firefox is the easiest way to get around that.

Comment 5

[Christopher May]

Attachment: Output for firefox crash

Comment 6

[Christopher May]

Thanks for the info so far people, heres the link with the Gentoo bug (https://bugs.gentoo.org/show_bug.cgi?id=279583)

Comment 7

[Tyler Downer [He/Him]]

Reporter, are you still seeing this issue with Firefox 3.6.12 or later in safe mode? If not, please close. These links can help you in your testing.
http://support.mozilla.com/kb/Safe+Mode
http://support.mozilla.com/kb/Managing+profiles
Also, please consider using the most recent Firefox 4 beta build, your bug may be resolved there.

Comment 8

[Christopher May]

Hi, I have noticed that since the 10x release of adobe-flash the problem seems to have solved itself. 

I think everyone agreed it was a flash issue and the evidence seems to agree :).

I vote to close this bug.

Thanks for your help.

Maq

Comment 9

[Tyler Downer [He/Him]]

No reply, INCOMPLETE. Please retest with Firefox 3.6.13 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.