Closed Bug 825786 Opened 7 years ago Closed 7 years ago

crash in nsAutoCompleteController::HandleDelete

Categories

(Toolkit :: Autocomplete, defect, critical)

x86
Windows NT
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla21

People

(Reporter: martijn.martijn, Assigned: mak)

Details

(Keywords: crash)

Crash Data

Attachments

(1 file, 1 obsolete file)

Steps to reproduce:
- Focus Search box
- Press the down arrow key to open up autocomplete popup
- Press again the down arrow key to select the first autocomplete entry
- Press and hold the del key to continuously delete items
- While doing that, click on the minimize button of the Firefox window.

Result: crash

Note that I have a lot of autocomplete entries in my search history. That might be necessary to trigger this crash.

This bug was filed from the Socorro interface and is 
report bp-ff49af59-e377-415f-9af4-c2f992130101 .
============================================================= 
0 	xul.dll 	nsAutoCompleteController::HandleDelete 	toolkit/components/autocomplete/nsAutoCompleteController.cpp:571
1 	xul.dll 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:70
2 	xul.dll 	XPCWrappedNative::CallMethod 	js/xpconnect/src/XPCWrappedNative.cpp:2383
3 	xul.dll 	XPC_WN_CallMethod 	js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1469
4 	mozjs.dll 	js::RunScript 	js/src/jsinterp.cpp:321
we should likely use the local input variable, looks like something earlier in the method may cause mInput to be set to null, that is why we make our own input pointer earlier.

I may eventually make a patch and generate a trybuild for you to test.
Assignee: nobody → mak77
Status: NEW → ASSIGNED
Marco, do you have a patch?
no, but I will make one today, thanks for the reminder.
Attached patch patch v1.0 (obsolete) — Splinter Review
I'm not sure I can come with a test, trying.
I wanted to send this to Try to give you a build but it's currently closed :(
Attached patch patch v1.1Splinter Review
the only way to make a test would be to have something explicitly setting input to null when called inside handleDelete, that doesn't look like a really good test :(

Based on the description, when minimize is hit it's likely there's a blur event, could be some nested loop causes the input to be detached and we are in the middle of handleDelete when it happen... But I was not able to reproduce in debug mode to figure at which point mInput becomes null.

I pushed this to try, maybe Martijn can try to reproduce with the try builds.
Attachment #702933 - Attachment is obsolete: true
Attachment #702962 - Flags: review?(enndeakin)
Attachment #702962 - Flags: review?(enndeakin) → review+
in the end takes less time to just push this and wait for a nightly, Try was closed and then overcrowded and the fix should be harmless.

https://hg.mozilla.org/integration/mozilla-inbound/rev/581b2c43af07
Target Milestone: --- → mozilla21
https://hg.mozilla.org/mozilla-central/rev/581b2c43af07
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Ok, it seems to be fixed, thanks.

I tried in a 20130101 nightly build, and I immediately got the crash.
Then I tried 2 times with a 20130117 nightly build, and I didn't get the crash.
Status: RESOLVED → VERIFIED
That's great, thank you Martijn
You need to log in before you can comment on or make changes to this bug.