Closed Bug 384879 Opened 17 years ago Closed 16 years ago

[@ nsAutoCompleteController::EnterMatch ]

Categories

(Toolkit :: Form Manager, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: timeless, Assigned: timeless)

References

()

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

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.
Assignee: nobody → timeless
Status: NEW → ASSIGNED
Attachment #268936 - Flags: review?(mconnor)
Attachment #268936 - Flags: review?(gavin.sharp)
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 on attachment 268936 [details] [diff] [review]
don't use objects after calling arbitrary javascript

a1.9=beltzner
Attachment #268936 - Flags: approval1.9? → approval1.9+
Depends on: 423967
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
Component: Satchel → Form Manager
Crash Signature: [@ nsAutoCompleteController::EnterMatch ]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: