Closed
Bug 384879
Opened 17 years ago
Closed 16 years ago
[@ nsAutoCompleteController::EnterMatch ]
Categories
(Toolkit :: Form Manager, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: timeless, Assigned: timeless)
References
()
Details
(Keywords: crash)
Crash Data
Attachments
(1 file)
12.70 KB,
patch
|
mconnor
:
review+
beltzner
:
approval1.9+
|
Details | Diff | Splinter Review |
I have venkman (actually this is venkman.fork) set to stop for exceptions and errors. unfortunately completion widgets generate such things and this gives things a much better chance of racing badly. Incident ID: 33232612 Stack Signature nsAutoCompleteController::EnterMatch 709fba11 Product ID FirefoxTrunk Build ID 2007061104 Trigger Time 2007-06-18 05:54:57.0 Platform Win32 Operating System Windows NT 5.1 build 2600 Module firefox.exe + (004a1cd8) URL visited using venkman User Comments Since Last Crash 17304 sec Total Uptime 189117 sec Trigger Reason Access violation Source File, Line No. e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\toolkit\components\autocomplete\src\nsautocompletecontroller.cpp, line 1125 Stack Trace nsAutoCompleteController::EnterMatch [mozilla/toolkit/components/autocomplete/src/nsautocompletecontroller.cpp, line 1125]
a bit of explanation might be in order. there are some general rules of xpcom. a basic one: Don't hold a Lock while calling code outside your module. here's a variant: Don't expect your code not to reenter if you call code outside your module that might perform arbitrary actions. here's an invariant: anytime you call javascript, arbitrary code can run before your javascript runs, while your javascript is running, and before control returns to you. including unless you're extremely careful, your own code, including that javascript. these rules apply to xpcom code. if your code is a web page, then there is a contract called "run to completion" (which absolutely does not apply to xpcom code, and for which there are accassional bugs) that says no other things will happen to the web page while its js is running. However, that's sort of an overstatement. If a web script decides to ask the web page for some coordinates, a reflow might be flushed, which could change the values of various coordinates of objects the page might have foolishly cached. one might claim that the behaviors we have wrt the debugger are unreasonable, however let's ignore that and note that at least occasionally this code calls notify observers and then tries to use an uncached pointer assuming it will still be valid.
Attachment #268936 -
Flags: review?(gavin.sharp)
Comment 3•16 years ago
|
||
Comment on attachment 268936 [details] [diff] [review] don't use objects after calling arbitrary javascript r=mconnor, seems pretty straightforward, my latency sucks
Attachment #268936 -
Flags: review?(mconnor) → review+
Attachment #268936 -
Flags: review?(gavin.sharp) → approval1.9?
Comment 4•16 years ago
|
||
Comment on attachment 268936 [details] [diff] [review] don't use objects after calling arbitrary javascript a1.9=beltzner
Attachment #268936 -
Flags: approval1.9? → approval1.9+
Comment on attachment 268936 [details] [diff] [review] don't use objects after calling arbitrary javascript mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp 1.80
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Updated•16 years ago
|
Component: Satchel → Form Manager
Updated•13 years ago
|
Crash Signature: [@ nsAutoCompleteController::EnterMatch ]
You need to log in
before you can comment on or make changes to this bug.
Description
•