firefox crashed randomly with segmentation fault

[Jojo]

Binary package hint: firefox-3.0

My FF crashes randomly with segmentation fault (core dupmed) signal. After a crash some times it is impossible to recover session, because of imminent crashes afterwards. I noticed that it crashes more often while browsing gmail or flash content pages. I include vallgrind log.

I use

Description: Ubuntu hardy (development branch)
Release: 8.04

FF version:
 *** 3.0~b4+nobinonly-0ubuntu1 0
        500 http://127.0.1.1 hardy/main Packages
        100 /var/lib/dpkg/status

[Tribes (tribes)]

Thank you for the bug report. Could you please try to obtain a backtrace by following the instructions on https://wiki.ubuntu.com/MozillaTeam/Bugs, or upload (as an attachment) the crash report from /var/crash/.

Also, please answer these questions:
Is this crash reproducible? If so, which are the steps that lead to it?
Which flash package do you have installed?
Which Java package do you have installed?
Which firefox extensions do you have installed?

This will greatly aid us in tracking down your problem.

[Iain Buclaw (iainb)]

I'm getting this too.

I think that it's certain types of "https" that don't work.

ie:
I can't login to Hotmail. Period.

ie2:
This link crashes firefox too, for a more direct form of reproducing this bug:
https://sourceforge.net/project/platformdownload.php?group_id=196339

I don't get any form of errors. The bug reporter doesn't signal that any crash has occured.

All I get from the terminal is:

:~$ firefox
Segmentation Fault (core dumped)

The latter prints only after firefox crashes.

______________________________________
firefox:
  Installed: 3.0~b4+nobinonly-0ubuntu1
  Candidate: 3.0~b4+nobinonly-0ubuntu1
  Version table:
 *** 3.0~b4+nobinonly-0ubuntu1 0
        500 http://gb.archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status
______________________________________
sun-java6-plugin:
  Installed: 6-05-0ubuntu1
  Candidate: 6-05-0ubuntu1
  Version table:
 *** 6-05-0ubuntu1 0
        500 http://gb.archive.ubuntu.com hardy/multiverse Packages
        100 /var/lib/dpkg/status
______________________________________
flashplugin-nonfree:
  Installed: 9.0.115.0ubuntu5
  Candidate: 9.0.115.0ubuntu5
  Version table:
 *** 9.0.115.0ubuntu5 0
        500 http://gb.archive.ubuntu.com hardy/multiverse Packages
        100 /var/lib/dpkg/status
______________________________________

The only extension I have is the Ubuntu Official Extension.
Though I have totem and mplayer addons for video streaming DivX, WMP, QT, etc.

Other than that, the only errors I've been recently seeing are:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
 LANGUAGE = (unset),
 LC_ALL = (unset),
 LANG = "en_GB.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

Though it's influence on firefox is probably very unlikely. Though I thought that it might be worth mentioning just incase.

Regards
Iain

[Iain Buclaw (iainb)]

Update, I've managed to get something.

And I've found that this may be a duplicate of the SIGSEGV bug thats hit everyone.
And as a result, these things don't work...?

https://bugs.launchpad.net/bugs/188540

Regards
Iain

[Jojo (kuzniarpawel)]

I was using the same java, flash packages as Iain Bucław. Now after upgrade to beta 5 FF sessions seems to be more stable. Probably it was Flash related bug, and my new bug report was premature.

[Matěj Cepl (mcepl)]

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b5) Gecko/2008043010 Fedora/3.0-0.60.beta5.fc9 Firefox/3.0b5
Build Identifier: firefox-3.0-0.60.beta5.fc9.x86_64 xulrunner-1.9-0.60.beta5.fc9.x86_64

(originally filed as Fedora bug https://bugzilla.redhat.com/show_bug.cgi?id=445199)

Core was generated by `/usr/lib64/firefox-3.0b5/firefox'.
Program terminated with signal 11, Segmentation fault.

#4 0x000000335b3e68f0 in nsVoidArray::EnumerateForwards (this=<value optimized
out>, aFunc=<value optimized out>, aData=<value optimized out>) at
nsVoidArray.cpp:678
678 running = (*aFunc)(mImpl->mArray[index], aData);
(gdb) list
673
674 if (mImpl)
675 {
676 while (running && (++index < mImpl->mCount))
677 {
678 running = (*aFunc)(mImpl->mArray[index], aData);
679 }
680 }
681 return running;
682 }
#3 0x000000335b3e3e80 in ReleaseObjects (aElement=<value optimized out>) at
nsCOMArray.cpp:151
151 NS_IF_RELEASE(element);
Current language: auto; currently c++
(gdb) list
146 // useful for destructors
147 PRBool
148 ReleaseObjects(void* aElement, void*)
149 {
150 nsISupports* element = static_cast<nsISupports*>(aElement);
151 NS_IF_RELEASE(element);
152 return PR_TRUE;
153 }
154
155 void
(gdb) down
#2 <signal handler called>
Current language: auto; currently c
(gdb) list
156 nsCOMArray_base::Clear()
157 {
158 mArray.EnumerateForwards(ReleaseObjects, nsnull);
159 mArray.Clear();
160 }
161
(gdb) down
#1 0x000000335ac268cd in nsProfileLock::FatalSignalHandler (signo=<value
optimized out>) at nsProfileLock.cpp:212
212 raise(signo);

Comment #1 From Martin Stransky (<email address hidden>) on 2008-05-05 09:26 EST [reply] Private

Can you please attach steps how to reproduce it?

Comment #2 From Harald Hoyer (<email address hidden>) on 2008-05-05 10:20 EST [reply] Private

1. create a new article in plone using the internal kupu editor.
2. write some text
3. click on ["html"]
4. boom

Comment #3 From Matej Cepl (<email address hidden>) on 2008-05-05 16:19 EST [reply] Private

(In reply to comment #2)
> 1. create a new article in plone using the internal kupu editor.
> 2. write some text
> 3. click on ["html"]
> 4. boom

Is there some internal (or publicly accessible external) instance of plone?

Comment #4 From Harald Hoyer (<email address hidden>) on 2008-05-05 22:25 EST [reply] Private

if you ping me on IRC, I can give you temporary access to my instance.

Comment #5 From Harald Hoyer (<email address hidden>) on 2008-05-06 00:45 EST [reply] Private

start firefox on x86_64:

login on:
https://test.harald-hoyer.de/login_form

User: test
PW: testit

go to:
https://test.harald-hoyer.de/personal/blog/augeas/edit

click in the big editor form. click on "HTML" in the editor toolbar.

Comment #6 From Martin Stransky (<email address hidden>) on 2008-05-06 04:11 EST [reply] Private

Hm, the provided testcase works fine for me (no crash). I have FF3 Beta5 with
internal cairo.

Comment #7 From Martin Stransky (<email address hidden>) on 2008-05-06 04:11 EST [reply] Private

on x86_64.

Comment #8 From Harald Hoyer (<email address hidden>) on 2008-05-06 04:36 EST [reply] Private

I'l...

[Timeless-bemail (timeless-bemail)]

if you're going to be filing bugs into our bugzilla, please:
. try to only copy meaningful comments
. include signature lines in your summaries when you file
. for crashes please select severity: critical
. for bugs in core, please file then in core instead of in firefox
. please select version: Trunk if you're using trunk (atm 3.0betas are trunk)
. please select version: {whatever is appropriate} if you aren't.

[Stransky (stransky)]

I can confirm the crash. Here is a backtrace from debug build:

#0 0x00002aaaac7a0a2e in ReleaseObjects (aElement=0x2aaabc143ce0) at nsCOMArray.cpp:151
#1 0x00002aaaac7a63cf in nsVoidArray::EnumerateForwards (this=0x2aaabc143e20, aFunc=0x2aaaac7a0a04 <ReleaseObjects>,
    aData=0x0) at nsVoidArray.cpp:678
#2 0x00002aaaac7a0a67 in nsCOMArray_base::Clear (this=0x2aaabc143e20) at nsCOMArray.cpp:158
#3 0x00002aaaac6f9347 in nsCOMArray<nsIAccessibleEvent>::Clear (this=0x2aaabc143e20)
    at ../../../dist/include/xpcom/nsCOMArray.h:217
#4 0x00002aaaac6f2ef0 in nsDocAccessible::FlushPendingEvents (this=0x2aaabc143cf0) at nsDocAccessible.cpp:1639
#5 0x00002aaaac6ef7df in nsDocAccessible::FlushEventsCallback (aTimer=0x2aaabc235190, aClosure=0x2aaabc143d98)
    at nsDocAccessible.cpp:1655
#6 0x00002aaaac811266 in nsTimerImpl::Fire (this=0x2aaabc235190) at nsTimerImpl.cpp:400
#7 0x00002aaaac81147a in nsTimerEvent::Run (this=0x2aaabc2c1b50) at nsTimerImpl.cpp:490
#8 0x00002aaaac80bd70 in nsThread::ProcessNextEvent (this=0x67d390, mayWait=1, result=0x7fffed5639bc) at nsThread.cpp:510
#9 0x00002aaaac7a998c in NS_ProcessNextEvent_P (thread=0x67d390, mayWait=1) at nsThreadUtils.cpp:227
#10 0x00002aaaac6aa9bc in nsBaseAppShell::Run (this=0x83ce90) at nsBaseAppShell.cpp:170
#11 0x00002aaaac46c0e6 in nsAppStartup::Run (this=0x94bdd0) at nsAppStartup.cpp:181
#12 0x00002aaaab8f91be in XRE_main (argc=1, argv=0x7fffed5675c8, aAppData=0x626e60) at nsAppRunner.cpp:3154
#13 0x0000000000401785 in main (argc=1, argv=0x7fffed5675c8) at nsXULStub.cpp:348
#14 0x00000038fc21e074 in __libc_start_main () from /lib64/libc.so.6
#15 0x0000000000400f39 in _start ()

aElement doesn't seem to be valid:

#0 0x00002aaaac7a0a2e in ReleaseObjects (aElement=0x2aaabc143ce0) at nsCOMArray.cpp:151
(gdb) p aElement
$5 = (void *) 0x2aaabc143ce0
(gdb) p* element
$6 = {_vptr.nsISupports = 0x5}

(gdb) up
#1 0x00002aaaac7a63cf in nsVoidArray::EnumerateForwards (this=0x2aaabc143e20, aFunc=0x2aaaac7a0a04 <ReleaseObjects>,
    aData=0x0) at nsVoidArray.cpp:678
(gdb) info locals
index = 0
running = 1
(gdb) p mImpl->mCount
$12 = 10922

[Stransky (stransky)]

(gdb) f
#4 0x00002aaaac6f2ef0 in nsDocAccessible::FlushPendingEvents (this=0x2aaabc143cf0) at nsDocAccessible.cpp:1639
(gdb) info locals
length = 0
presShell = {mRawPtr = 0x0}

[Stransky (stransky)]

The mEventsToFire.Clear(); NS_RELEASE_THIS(); combo is called twice for the same nsDocAccessible instance. First from:

#0 nsDocAccessible::Shutdown (this=0x3046680) at nsDocAccessible.cpp:583
#1 0x00002aaaac6e6e2e in nsAccessNode::GetPresShell (this=0x3046680) at nsAccessNode.cpp:347
#2 0x00002aaaac6f247a in nsDocAccessible::FlushPendingEvents (this=0x3046680) at nsDocAccessible.cpp:1494

and then from nsDocAccessible::FlushPendingEvents itself.

[Ginn-chen (ginn-chen)]

Good catch, thank you.

Perhaps we should add a bool member to record whether the kung fu death grip is released.

[Ginn-chen (ginn-chen)]

I don't have a chance to reproduce the crash stack like comment #2.

I tried kupu editor test page.
http://www.craic.com/oreilly/kupu/kupu/common/kupu.html

I got a lot ASSERTs of a11y module with debug build, and got several different crash stacks with release build, but none of them are crashed in a11y module.
But I think it's related to a11y, because I can't crash Firefox with a11y off.

[Ginn-chen (ginn-chen)]

Finally I got it reproduced. Taking.

[Ginn-chen (ginn-chen)]

Created attachment 320109
patch

Make sure we're not released twice.

[Aaronleventhal (aaronleventhal)]

Ginn, can you explain what happens? How do we end up in Shutdown() while in the middle of flushing pending events?

[Ginn-chen (ginn-chen)]

1506 NS_IMETHODIMP nsDocAccessible::FlushPendingEvents()
1507 {
1508 PRUint32 length = mEventsToFire.Count();
1509 NS_ASSERTION(length, "How did we get here without events to fire?");
1510 nsCOMPtr<nsIPresShell> presShell = GetPresShell();
1511 if (!presShell)
1512 length = 0; // The doc is now shut down, don't fire events in it anymore

Calling GetPresShell() may cause the doc be shut down.
See comment #4.

[Aaronleventhal (aaronleventhal)]

Then should we also change the event loop in FlushPendingEvents() to see if the doc is shut down, and if so, exit early?

[Mtschrep (mtschrep)]

Aaron can I get a priority/risk assessment for this bug? We are mostly locked down for final release and would only take showstoppers at this point.

[Mtschrep (mtschrep)]

Only taking showstopper issues at this point. If this is one of those please re-nom with why.

[Aaronleventhal (aaronleventhal)]

Comment on attachment 320109
patch

I don't see anything risky in the patch, and it's always good to keep working on a11y crashes. We don't get as much testing coverage as other stuff does but we do try to deal with our crash reports. It's hard to say how much this will happen for Firefox 3 users.

[Alexander Surkov (surkov-alexander)]

Ginn, we can fail at http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/accessible/src/base/nsDocAccessible.cpp&rev=1.243#1628. It would mean we won't release kung fu grip, right?

[Alexander Surkov (surkov-alexander)]

Comment on attachment 320109
patch

r=me

[Alexander Surkov (surkov-alexander)]

(In reply to comment #15)
> Ginn, we can fail at
> http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/accessible/src/base/nsDocAccessible.cpp&rev=1.243#1628.
> It would mean we won't release kung fu grip, right?
>

Ginn, would you like to fix this in the bug?

[Ginn-chen (ginn-chen)]

Created attachment 320499
patch v2

Addressing surkov's comment.

[Alexander Surkov (surkov-alexander)]

Comment on attachment 320499
patch v2

r=me, asking approval, see comment #14

[Marco-zehe (marco-zehe)]

Requesting that this be considered should we need a respin for RC2. Since I don't know of a better way, I put something to that effect in the status whiteboard.

[Mtschrep (mtschrep)]

added [RC2?] to whiteboard to make sure it is considered if there is an RC2

[Shaver (shaver)]

Not for RC2, can take for 1.9.0.1 if it proves out -- please get a test up as soon as you can.

[EliCoten (launchpad-elicoten)]

I have had this problem only since upgrading to Hardy. When I first installed Gusty I had a similar problem but then the problem disappeared.

Now I've upgraded the problem has come back again. I tried installing SwiftWeasel 2.0.0.14, which is very slightly more reliable (and a lot faster) but that also crashes randomly.

When Firefox crashes there is just a note in the terminal "segmentation fault".

I noticed it happens more often when accessing big pages like GMail, Google Docs, and Facebook - but it has happened at all different times. Sometimes when scrolling up/down long pages or closing tabs but it seems pretty random.

[Jojo (kuzniarpawel)]

Check your RAM. In my case it was a hardware issue. Replacing RAM solved the problem. Apparently memtest can not often diagnose the problem.

[EliCoten (launchpad-elicoten)]

Then why does Opera not exhibit the same problem? I am short of RAM (256Mb) but surely it isn't right that Firefox should just disappear on low-memory systems?

If there was an issue with RAM, why would it affect Firefox3b5, and SwiftWeasel 2.0.0.14 but not Opera (or any other program for that matter?)

[Jojo (kuzniarpawel)]

Apparently there is a flash related bug, but in my case initial symptoms were exactly the same. Only FF crashed randomly. Opera was rock solid, as was the rest of software was using on daily basis. I diagnosed the problem only because one day things got really bad, and I started to have segmentation faults randomly in all programs. In my case one of 1GB memory modules was broken. All worked stable as far as only some part of RAM was used. But when memory usage reached certain level I received seg faults. Unfortunately only FF consumed enough RAM to encounter this issue. I checked again plugging only the fault module and system became totally unstable.

Surely there is a bug in flashplugin-nonfree but it causes FF to crash on flash content. You could try replacing nonfree with gnash.

Try to debug the crash to see what is the main cause of crashes.

[Marco-zehe (marco-zehe)]

Ginnk Surkov, can you work on getting a Mochitest testcase up for this? Thanks!

[Ginn-chen (ginn-chen)]

Macro, I don't know how to write a mochitest for this.

Surkov, do you have an idea?

[EliCoten (launchpad-elicoten)]

Hi

It could be a flash related bug but that doesn't explain why GMail often triggers the crash.

As I said previously I only have 256Mb RAM and if the module was faulty, I think it would cause more problems than just with Firefox. Its not possible that its not being used because there is only one module in this system - its not like "only one of them" is faulty because there is only one in total.

How do I debug the crash? Its not really a crash - more that it just randomly closes but if I run it from a terminal it does say Segmentation fault.

Also if the problem is with the flash plugin why didn't it make problems on Gusty? Why is it only since I've upgraded to Hardy (with Firefox 3) that I notice the problem?

[Jojo (kuzniarpawel)]

read here

https://wiki.ubuntu.com/MozillaTeam/Bugs?action=show&redirect=DebuggingFirefox

[Alexander Surkov (surkov-alexander)]

That's hard to think of mochitest for this but in any way for this we could try to reproduce user actions in JS. Ginn, could you please put your steps to reproduce the bug?

[Ginn-chen (ginn-chen)]

My reproduce steps:

1) Open Firefox 3 with GNOME a11y enabled and keep accerciser running behind
2) Open kupu editor test page
http://www.craic.com/oreilly/kupu/kupu/common/kupu.html
3) Set focus to editor box, press Ctrl+A to select all the content, press delete
4) Find the "edit HTML code" button in kupu toolbar, click it.
5) click the "edit HTML code" button again to switch back.
6) repeat step 4)-5) several times, Firefox should not be hang or crash.

Note: If you're using a release build, the stack could be anywhere that calling free().

[Alexander Sack (asac)]

On Wed, May 28, 2008 at 01:34:48PM -0000, Jojo wrote:
> read here
>
> https://wiki.ubuntu.com/MozillaTeam/Bugs?action=show&redirect=DebuggingFirefox
>

please attach the proper backtrace. read the page above to get
instructions on how to get a backtrace on hardy.

 status incomplete

 - Alexander

[Ted Mielczarek (ted-mielczarek)]

*** Bug 436375 has been marked as a duplicate of this bug. ***

[Ted Mielczarek (ted-mielczarek)]

Looks like this affects all Tablet PC users too, from bug 436375.

[Ted Mielczarek (ted-mielczarek)]

And by "affects" I mean "Tablet PC users are crashing randomly".

[Martijn-martijn (martijn-martijn)]

Bug 418142 is about the same issue, I guess?

[Ted Mielczarek (ted-mielczarek)]

Martijn: does the build with the patch applied fix your crashes?

[Beltzner (beltzner)]

Renominating: bug 436375 implies that this particular bug nets out to "user on tablet PCs will have a pretty bad experience with Firefox 3". Options are:

 - relnote
 - respin

[Martijn-martijn (martijn-martijn)]

*** Bug 418142 has been marked as a duplicate of this bug. ***

[Martijn-martijn (martijn-martijn)]

(In reply to comment #31)
> Martijn: does the build with the patch applied fix your crashes?

You mean the build with the patch from bug 436375, comment 23?
Yes, tat seems to fix the crash.

I've marked bug 418142 now as a duplicate of this bug.
That bug has minimal testcases attached, btw.

I'm glad this bug is getting fixed, I was hitting this kind of crash all the time while testing with accessibility.

[Beltzner (beltzner)]

The bug will be fixed, though it's unclear if it will cause a respin.

It would help if we could get:
  - an understanding of what code is being called by Windows Tablet PCs
  - a rough estimate of how many crashes we're seeing from this
  - a rough understanding of marketshare for Tablet PCs

[Beltzner (beltzner)]

From bug 434752 comment 10:

> oh, right, the input panel. i knew it was used somewhere. thanks!
>
> http://msdn.microsoft.com/en-us/library/ms818403.aspx
> http://msdn.microsoft.com/en-us/library/ms811573.aspx

Marco says that he can't reproduce this crash with the samples in bug 418142 provided by mw22.

Looking through what this patch fixes, I heavily suspect that it was caused by bug 403260, but that's just an allegation at this point :)

[Marco-zehe (marco-zehe)]

The top crasher with FlushPendingEvents somewhere in the top 10 frames is this one, with a total of 138 in the last 4 weeks:
http://crash-stats.mozilla.com/report/list?range_unit=weeks&query_search=stack&query_type=contains&product=Firefox&platform=windows&version=Firefox%3A3.0&branch=1.9&signature=nsCOMPtr_base%3A%3A~nsCOMPtr_base()&query=FlushPendingEvents&range_value=4

All others are below 20 and with varying signatures.

[Ted Mielczarek (ted-mielczarek)]

We may be able to look for crash reports whose module list contains "tiptsf.dll". This seems to be the input panel module. This may get more than we want, but since people are crashing randomly, it seems pretty likely that their crashes would be related to this.

[Olistrut (olistrut)]

(In reply to comment #35)
> It would help if we could get:
> - a rough understanding of marketshare for Tablet PCs

I don't have access to the full reports, but according to an IDC report quoted by channelinsider, Tablet PCs had a market share of more than 7% of the overall mobile PC market (http://www.channelinsider.com/c/a/Tech-Analysis/Time-to-Talk-About-Tablet-PCs/) and notebooks represent roughly 30% of the overall PC market (http://news.cnet.com/Notebooks-continue-shipment-gains/2100-1044_3-5070313.html).

So this bug should roughly affect 7%*30%=2.1% percent of the user base. And it hits them hard: I have seen days with more than 20 random crashes on my tablet PC.

[Marco-zehe (marco-zehe)]

Fix has been checked into mozilla-central in changeset 263749849d0b. Leaving bug open until we check this into the 1.9.0 branch.

[EliCoten (launchpad-elicoten)]

I'm running Firefox 3 now in debug mode. It took about 10x longer to start, and it seems to be running much slower but it seems not to crash (not in debug mode it crashes within a minute of being started if I leave it alone - if I start using it then I can sometimes get it to work for a while).

Will post back if/when it crashes. So far its been slow but stable.

[EliCoten (launchpad-elicoten)]

It did crash eventually but not as quickly as usual. See attachment. It took a very long time for GDB to load and then product the backtraces, is that normal? Or is it just because I don't have much RAM?

[Marcia-mozilla (marcia-mozilla)]

We received the IBM tablet PC from Toronto and I installed it in the QA lab for testing. It is running Windows XP PC Tablet Edition 2005 with SP 2. I was not able to reproduce the issue cited in this bug with RC2.

[Alexander Sack (asac)]

On Thu, Jun 05, 2008 at 10:42:38PM -0000, EliCoten wrote:
> It did crash eventually but not as quickly as usual. See attachment. It
> took a very long time for GDB to load and then product the backtraces,
> is that normal? Or is it just because I don't have much RAM?
>
> ** Attachment added: "gdb-firefox.txt"
> http://launchpadlibrarian.net/15068213/gdb-firefox.txt
>

OK, can you still reproduce this? Can you please test with firefox 3
RC1 in hardy-proposed?

 status incomplete

 - Alexander

[Alexander Sack (asac)]

upstream has a patch. you have any chance to test that without use spinning test packages for this?

[EliCoten (launchpad-elicoten)]

I'm a bit confused - what does this mean "you have any chance to test that without use spinning test packages for this?"

What are spinning packages?

Also why is Firefox 3RC1 taking so long to be released to all Hardy users? I think the Mozilla team have now released RC2?

I'm not entirely certain what you'd like me to do next. (I'm not on my Ubuntu machine now so if there are any recently released updates I won't have seen them yet)

[Marco-zehe (marco-zehe)]

Comment on attachment 320499
patch v2

Requesting that this be allowed to land for 3.0.1:

- It already has blocking status.
- It has been determined that this fixes a big heap of problems like bug 436375 for tablet PCs.
- The testcase in bug 418142 no longer crashes with this patch in place.

Question: Is there a way to turn that testcase into a regular mochitest? Or should these not be mochitests since they are strictly spoken not unit tests but a crash test instead?

[Matti-mversen (matti-mversen)]

*** Bug 440205 has been marked as a duplicate of this bug. ***

[Ted Mielczarek (ted-mielczarek)]

Marco: we have a set of crash tests that gets run on the unit test boxes:
http://developer.mozilla.org/en/docs/Mozilla_automated_testing#Crash_tests

They're set up just like reftests, but the point is that they should run without crashing. If this testcase can reproduce the crash without a11y enabled, then it should be easy to make a crash test from it.

[Marco-zehe (marco-zehe)]

(In reply to comment #44)
> If this testcase can reproduce the crash without a11y
> enabled, then it should be easy to make a crash test from it.

No, that's the whole point, without a11y, this crash will never happen. That's why mostly people using a Tablet PC see this, and hardly any others. Tablet PC uses a11y stuff and thus enables this faulty code.

[car-los (karol-banczyk)]

Hello,

I thought that maybe this tip could solve the problem:
http://www.ubuntugeek.com/fix-for-firefox-crashes-on-flash-contents-when-using-libflashsupport-in-hardy.html

I thought initially it would but then I get still crashes while closing tabs. I'm not sure yet, but maybe mainly gmail tabs crash the browser. There is another bug for this one, I think.

regs.

[Beltzner (beltzner)]

Although, confusingly, Marcia's report in comment 41 indicates that it isn't affecting all Tablet PC users. Do we know if it's only Tablet PC w/Vista?

Marco: this landed on central; are we seeing any other regressions or problems with the patch?

Until we know that, I'm moving this back down to nominated for 1.9.0.1, but wanted on 1.9.0.x; I'll be looking at patch approvals later tonight or tomorrow.

[Marco-zehe (marco-zehe)]

(In reply to comment #46)
> Although, confusingly, Marcia's report in comment 41 indicates that it isn't
> affecting all Tablet PC users. Do we know if it's only Tablet PC w/Vista?

No, it's also Tablet PCs running XP, see bug 436375, and that reporter's machine was completely fixed once he ran a custom build Ted made for him with this patch applied.

> Marco: this landed on central; are we seeing any other regressions or problems
> with the patch?

No, not as far as I can see. I've been running both nightlies for the past days, and also did various test development on builds I made from Central, and am not seeing any regressions.

I'd also give you some info about crashes reported on 3.1a1pre (if any), if crash-stats sent me something, but it is in a bad mood today.

[Marco-zehe (marco-zehe)]

Setting bug to fixed in accordance to rules laid out by Sam in mozilla.dev.planning. Landed on mozilla-central a few weeks ago already, see comment #40.

[Iain Buclaw (iainb)]

As far as I'm concerned, this has been fixed in Intrepid :)

I followed that howto link in car-los's post above, then pinned hardy/added intrepid to my sources list.

Then upgraded to firefox 3.0 and Flash 10 beta using the "/t intrepid" option in apt-get, et Voila!

I've had no crashes since (this was 8 days ago).

Regards
Iain

[Beltzner (beltzner)]

Comment on attachment 320499
patch v2

a=beltzner

[Marco-zehe (marco-zehe)]

Checking in accessible/src/base/nsDocAccessible.cpp;
/cvsroot/mozilla/accessible/src/base/nsDocAccessible.cpp,v <-- nsDocAccessible.cpp
new revision: 1.245; previous revision: 1.244
done
Checking in accessible/src/base/nsDocAccessible.h;
/cvsroot/mozilla/accessible/src/base/nsDocAccessible.h,v <-- nsDocAccessible.h
new revision: 1.80; previous revision: 1.79
done

[Marcia-mozilla (marcia-mozilla)]

Can the reporter or someone who was able to reproduce the crash on tablet PC please download the nightly and confirm that this fixes the crash? I haven't been able to reproduce the issue on the tablet PC we have in the QA lab.

[Htonoyan (htonoyan)]

I no longer have this issue with version 3.1a1pre

[Martijn-martijn (martijn-martijn)]

Verified fixed, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
by using the testcases in bug 418142.
I used to crash with those in Firefox 3.0, but not anymore, with the Firefox3.0.1 build.

[Matti-mversen (matti-mversen)]

*** Bug 443637 has been marked as a duplicate of this bug. ***

[Matti-mversen (matti-mversen)]

*** Bug 445060 has been marked as a duplicate of this bug. ***

[Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount)]

I am closing it because the bug has been fixed upstream. Thanks.

[Marco-zehe (marco-zehe)]

This landed on m-c in June of 2008 when that was still 1.9.1, and should've been marked verified ages ago. Sorry!