461813 - crash in [@ nsFrameSelection::HandleDrag]

Status: VERIFIED FIXED

(Core :: DOM: Selection, defect)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Crash report:
http://crash-stats.mozilla.com/report/index/a795e040-a45f-11dd-b7a9-001cc4e2bf68?p=1

Almost certainly caused by https://bugzilla.mozilla.org/show_bug.cgi?id=459921#c13 -- filing this bug to track a fix, since i'm not sure if it just needs a null check or needs some more code around it.

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: potential fix

I crash in this at least 2-3x daily.  Not sure if this is the right fix codewise, but it would make my crash go away.

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think that null check should go down inside the "if (NS_SUCCEEDED(frame->...))"

Comment 3

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

The crash is the NS_SUCCEEDED bit, not the later one.  That is, GetFrameForNodeOffset is returning NULL, so that whole block wouldn't do much, right?

Comment 4

[Martijn Wargers (dead)]

Is this the same as this crash?
http://crash-stats.mozilla.com/report/index/35b14c21-a61b-11dd-b43a-001321b13766?p=1
If so, I might be able to get a testcase, if wanted.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I mean it should be "if (frame && NS_SUCCEEDED(frame->...))", like the similar code below.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

A crashtest would be good.

Comment 7

[Martijn Wargers (dead)]

Attachment: testcase (uses enhanced privileges)

Ok, I get the crash I mentioned with this testcase. Just move your mouse over the window of the testcase, it should crash very soonish.
I tried to make a fully automated testcase that crashes, by using mousemove events, but I didn't succeed at that.

Comment 8

[(mostly gone) XtC4UaLL [:xtc4uall]]

bp-4f3f1347-a6c9-11dd-80d1-001a4bd43ef6 using Windows XP with same stack as the crash mentioned in #c4.

Comment 9

[Uri Bernstein]

Sorry for not being around to fix this, and thanks, Vlad, for providing a fix.

Comment 10

[Dave Camp (:dcamp)]

Landed as http://hg.mozilla.org/mozilla-central/rev/a478d6238551

Comment 11

[Martijn Wargers (dead)]

The testcase I attached to this bug is still crashing in current trunk build, so I filed bug 466856 for that.

Comment 12

[Aakash Desai [:aakashd]]

I'm not sure what's up with this bug as it's in a Resolved:FIXED state, while the last comment states that the bug is still crashing in the "current" trunk build on 11/26/2008. Can we get an update on this?

Comment 13

[Martijn Wargers (dead)]

This bug is fixed, I filed a new bug for the testcase that I attached.

Comment 14

[Aakash Desai [:aakashd]]

verified FIXED on builds: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090413 Minefield/3.6a1pre ID:20090413031052

and

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090413 Minefield/3.6a1pre ID:20090413031052

Comment 15

[Aakash Desai [:aakashd]]

ack, here's the build ID for Shiretoko Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090413 Shiretoko/3.5b4pre ID:20090413031313