readonly attribute allows incorrect garbage collection

RESOLVED INCOMPLETE

Status

()

RESOLVED INCOMPLETE
16 years ago
a year ago

People

(Reporter: rainking, Unassigned)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
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

16 years ago
Formally confirming for consideration -
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: dbradley → nobody
QA Contact: pschwartau → xpconnect
It looks like this was never verified as really happening, so I'm just going to close this as incomplete.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.