Closed
Bug 190882
Opened 22 years ago
Closed 7 years ago
readonly attribute allows incorrect garbage collection
Categories
(Core :: XPConnect, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: rainking, Unassigned)
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 This may be difficult to prove, but I'll try my best. While writing code for Annozilla, a javascript annotations application for mozilla (annozilla.mozdev.org), I noticed that whenever I had a great volume of annotations, a readonly field inside an XPCOM object would suddenly become inaccessible for no particular reason. Specifically, I had defined an interface for annotations, nsIAnnotation. The relevant part of this interface is: /** * An annotation. */ [scriptable, uuid(1c92ccef-0603-4d29-b305-ee4d59b43d38)] interface nsIAnnotation : nsISupports { /** * Metadata for this annotation. */ readonly attribute nsIAnnotationMetadata data; ... continued ... } For full reference, both the nsIAnnotationMetadata dn nsIAnnotation interfaces are in: http://www.mozdev.org/source/browse/annozilla/service/idl/Attic/nsIAnnotations.idl?rev=1.1.2.26&content-type=text/x-cvsweb-markup&only_with_tag=ANNOTATIONS_SERVICE As I encountered a great volume of annotations, eventually I would receive a javascript error that the field myAnnotation.data was undefined. This would be quite perplexing to me, as no operation within the nsIAnnotation class ever deleted the data field. Additionally, since the data field was readonly, no external agent should be able to write over it. This problem always occurred at seemingly random times--no one annotation was the cause, and sometimes it wouldn't happen for a while. This nondeterminism leads me to suspect a garbage-collection related problem. Anyhow, I noticed that the data field was all that disappeared--the other fields in the annotation remained intact. Observing this, I noticed that the data field was the only readonly field. I tried removing the readonly attribute, and henceforth there were never any problems. While I realize this is not a rigorous proof, I highly suspect that readonly attributes that are XPCOM objects are being incorrectly garbage collected, a behavior which stops when the readonly designation is removed. Reproducible: Sometimes Steps to Reproduce: 1. 2. 3.
Comment 1•22 years ago
|
||
Formally confirming for consideration -
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•18 years ago
|
Assignee: dbradley → nobody
Updated•18 years ago
|
QA Contact: pschwartau → xpconnect
Comment 2•7 years ago
|
||
It looks like this was never verified as really happening, so I'm just going to close this as incomplete.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•