Closed
Bug 375196
Opened 18 years ago
Closed 18 years ago
crashes [@ nsVoidArray::RemoveElementsAt][@ nsTextControlFrame::FireOnInput]
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: smaug, Assigned: smaug)
References
()
Details
(4 keywords, Whiteboard: [sg:critical?] null-deref on 1.8 branch?)
Crash Data
Attachments
(3 files)
1.15 KB,
patch
|
Details | Diff | Splinter Review | |
21.97 KB,
patch
|
roc
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
24.23 KB,
patch
|
roc
:
review+
roc
:
superreview+
dveditz
:
approval1.8.1.4+
dveditz
:
approval1.8.0.12+
|
Details | Diff | Splinter Review |
See bug 375093
talkback ID: TB30519322Z
MSVCR80.dll + 0x1520a (0x7814520a)
nsVoidArray::RemoveElementsAt [mozilla/xpcom/build/nsvoidarray.cpp, line 591]
nsTextControlFrame::FireOnInput [mozilla/layout/forms/nstextcontrolframe.cpp,
line 2472]
nsTextInputListener::EditAction [mozilla/layout/forms/nstextcontrolframe.cpp,
line 517]
nsEditor::NotifyEditorObservers [mozilla/editor/libeditor/base/nseditor.cpp,
line 1795]
nsAutoPlaceHolderBatch::~nsAutoPlaceHolderBatch
[mozilla/editor/libeditor/base/nseditorutils.h, line 66]
Possible fix
https://bugzilla.mozilla.org/attachment.cgi?id=259517
Comment 1•18 years ago
|
||
I can reproduce this crash with a 2007-03-24 trunk build.
But I haven't been able to reproduce it with my debug build.
If someone can reproduce this crash in its own built build and then try out Olli's patch, that would be great.
Comment 2•18 years ago
|
||
Btw, I sometimes can reproduce this crash (in 20% of the cases) when right-clicking pasting in the text input.
Comment 3•18 years ago
|
||
(In reply to comment #1)
> If someone can reproduce this crash in its own built build and then try out
> Olli's patch, that would be great.
I can reproduce this crash in my debug build and the suggested patch
fixed it.
Assignee | ||
Comment 4•18 years ago
|
||
Assignee: events → Olli.Pettay
Status: NEW → ASSIGNED
Attachment #259578 -
Flags: review?(mats.palmgren)
Comment 5•18 years ago
|
||
Should we fix CheckFireOnChange and NotifySelectionChanged too?
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/forms/nsTextControlFrame.cpp&rev=3.252&root=/cvsroot&mark=314,2492#278
and nsListControlFrame::FireOnChange?
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/forms/nsListControlFrame.cpp&rev=1.417&root=/cvsroot&mark=1663#1643
and perhaps document in nsIPresShell.h that callers of
HandleEventWithTarget and HandleDOMEventWithTarget
guaranties that a strong ref exist for the duration of the call.
Ditto for HandleEvent in nsIViewObserver.h (which PresShell implements)
-or- should we leave the callers as is and make the above HandleEvent
methods hold a strong ref on 'this'?
Assignee | ||
Comment 6•18 years ago
|
||
Caller of HandleEventWithTarget or HandleDOMEventWithTarget should keep
strong ref. Just going through all those cases ...
Group: security
Assignee | ||
Updated•18 years ago
|
Attachment #259578 -
Flags: review?(mats.palmgren)
Assignee | ||
Comment 7•18 years ago
|
||
I think we want to have a version for branches too.
Attachment #259585 -
Flags: superreview?(roc)
Attachment #259585 -
Flags: review?(roc)
Comment on attachment 259585 [details] [diff] [review]
using nsCOMPtr<nsIPresShell>
// shell may no longer be alive, don't use it here unless you keep a ref
You could remove this comment.
Attachment #259585 -
Flags: superreview?(roc)
Attachment #259585 -
Flags: review?(roc)
Attachment #259585 -
Flags: review+
Attachment #259585 -
Flags: superreview+
Assignee | ||
Updated•18 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 9•18 years ago
|
||
Similar for branches.
1.8.0/nsGfxScrollFrame.cpp needs to be fixed manually when applying the
patch.
Attachment #259780 -
Flags: superreview?(roc)
Attachment #259780 -
Flags: review?(roc)
Attachment #259780 -
Flags: approval1.8.1.4?
Attachment #259780 -
Flags: approval1.8.0.12?
Summary: crashes [@ nsVoidArray::RemoveElementsAt][@ nsTextControlFrame::FireOnInpu] → crashes [@ nsVoidArray::RemoveElementsAt][@ nsTextControlFrame::FireOnInput]
Comment 10•18 years ago
|
||
On an unfixed trunk debug build I get a deleted PresShell, on the 1.8 branch it
appears to be a relatively safe null-deref DoS. DeCOMtamination went too far on
the trunk? Better to just fix it though, just in case.
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x+
Flags: blocking1.8.1.4+
Flags: blocking1.8.0.12+
Whiteboard: [sg:critical?] null-deref on 1.8 branch?
Attachment #259780 -
Flags: superreview?(roc)
Attachment #259780 -
Flags: superreview+
Attachment #259780 -
Flags: review?(roc)
Attachment #259780 -
Flags: review+
Comment 11•18 years ago
|
||
Comment on attachment 259780 [details] [diff] [review]
for branches
approved for 1.8.0.12 and 1.8.1.4, a=dveditz for release-drivers
Attachment #259780 -
Flags: approval1.8.1.4?
Attachment #259780 -
Flags: approval1.8.1.4+
Attachment #259780 -
Flags: approval1.8.0.12?
Attachment #259780 -
Flags: approval1.8.0.12+
Assignee | ||
Updated•18 years ago
|
Keywords: fixed1.8.0.12,
fixed1.8.1.4
Comment 12•18 years ago
|
||
Verified fixed, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070403 Minefield/3.0a4pre
Status: RESOLVED → VERIFIED
Updated•18 years ago
|
Group: security
Updated•17 years ago
|
Flags: in-testsuite?
Updated•14 years ago
|
Crash Signature: [@ nsVoidArray::RemoveElementsAt]
[@ nsTextControlFrame::FireOnInput]
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•