190882 - readonly attribute allows incorrect garbage collection

Status: RESOLVED INCOMPLETE

(Core :: XPConnect, defect)

Description

[Doug Daniels]

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

[Phil Schwartau]

Formally confirming for consideration -

Comment 2

[Andrew McCreight [:mccr8]]

It looks like this was never verified as really happening, so I'm just going to close this as incomplete.