Another Crash on testcase from 489647 with accessibility enabled in [@nsTextFrame::ClearTextRun()]

VERIFIED FIXED

Status

()

defect
VERIFIED FIXED
10 years ago
10 years ago

People

(Reporter: asac, Unassigned)

Tracking

({verified1.9.0.11})

1.9.0 Branch
x86
Linux
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.0.11 +
wanted1.9.0.x +
wanted1.8.1.x -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:dupe 472776])

Attachments

(1 attachment)

Reporter

Description

10 years ago
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042315
Firefox/3.0.10

Seems, I can still make firefox 3.0.10 crash by enabling accessibility in gnome
on ubuntu jaunty, like:

1.  gconftool-2 --set --type=bool /desktop/gnome/interface/accessibility true
2.  ./firefox https://bugzilla.mozilla.org/attachment.cgi?id=374249

Sample Crash:
 
http://crash-stats.mozilla.com/report/index/34ac9c9a-9a6d-4ce6-b4e7-7ace62090427

Comment 1

10 years ago
FYI for automated testing-- the above doesn't always crash immediately. Eg, I would use a file:/// URL and most of the time I would need to click 'Reload' to trigger the crash (though occasionally I wouldn't).
FWIW, I couldn't reproduce this, after a minute or two of repeated reloading, using latest-mozilla1.9.0:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090426 Minefield/3.6a1pre
Since bug 489647 was blocking, if we can reproduce this, it should block too.
Flags: blocking1.9.0.11?
Just enabling accessibility is enough to get this crash, as was already said.
(In reply to comment #2)
> FWIW, I couldn't reproduce this, after a minute or two of repeated reloading,
> using latest-mozilla1.9.0:
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090426
> Minefield/3.6a1pre

Daniel, the build id you posted wasn't from a 1.9.0.x build, but from a trunk build, so I guess you tested with a trunk build and not with a 1.9.0.x build.
Ah, good catch on that build ID... I'd swear I tested with a 1.9.0.x nightly on that machine, but maybe I forgot the "-no-remote" command-line arg or something.

In any case, I've downloaded a 1.9.0.x nightly on my laptop now, and I can definitely reproduce the bug here, both with the old bug's testcase (with accessibility enabled) and with Martijn's new automatic-accessibility-enabling testcase attached on this bug.

Sample crash report:
http://crash-stats.mozilla.com/report/index/acf72021-9bb1-49de-96d0-adefa2090428

Build ID:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.11pre) Gecko/2009042804 GranParadiso/3.0.11pre
In theory, we should be able to hit this crash with a mozilla-central build/nightly from just after bug 467150's patch landed, and then track down a fix range from there, to see what patch fixed this additional crash.
(In reply to comment #7)
> In theory, we should be able to hit this crash with a mozilla-central
> build/nightly from just after bug 467150's patch landed

Cool -- I tried the mozilla-central nightly build from 2008/12/17 (right after bug 467150 landed), and it crashed on this bug's testcase, after reloading repeatedly for ~10 sec.

I tried the 2008/12/20 nightly (a few days later) to make sure the 12/17 one wasn't just particularly crashy, and the 12/20 build crashed on this bug's testcase, too.

Sadly, the crash report doesn't seem to have symbols available.
http://crash-stats.mozilla.com/report/index/c62340e5-896a-40d6-a3c5-a975a2090428
http://crash-stats.mozilla.com/report/index/b72d40c7-c4b2-45c3-8d20-7110b2090428

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20081217 Minefield/3.2a1pre
I traced the crash to being fixed in mozilla-central between these nightlies:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090223 Minefield/3.2a1pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090224 Minefield/3.2a1pre

That yields this regression range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b84ee6f45b08&tochange=69c86f3acc5a

That range includes the fix for bug 472776, which I think is the exact same as this bug -- it's a crash [@ UnhookTextRunFromFrames] and [@ ClearAllTextRunReferences], which exactly matches the stacks I've been getting from Martijn's testcase here, e.g.
http://crash-stats.mozilla.com/report/index/d005a5b3-613e-46ba-8fce-503602090428

So, I think this crash here is effectively a dupe of bug 472776.
The patch in bug 472776 applies cleanly on 1.9.0.x (aside from 'crashtests.list') -- I tried it out, and it does indeed fix this crash.
(Though FWIW, I haven't ever been able to reproduce the shutdown crash from bug 472776's testcase in a 1.9.0.x build.  That's not a huge deal, though -- it just means there are additional factors involved that caused that particular testcase to fail on mozilla-central.)
Depends on: 472776
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.11?
Flags: blocking1.9.0.11+
Whiteboard: [sg:critical?]
Whiteboard: [sg:critical?] → [sg:critical?][sg:dupe 472776]
The fix for bug 472776 just landed on 1.9.0.x, so this should now be fixed.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [sg:critical?][sg:dupe 472776] → [sg:dupe 472776]
I verified this on Ubuntu 8.10 with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.11pre) Gecko/2009051104 GranParadiso/3.0.11pre. I also verified the crash with 1.9.0.10 on the same system. So this is fixed.
Status: RESOLVED → VERIFIED
Flags: wanted1.8.1.x-
Group: core-security
You need to log in before you can comment on or make changes to this bug.