Bug 1577311 Comment 11 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Original comment by
on 
The debug information just tells us, that we have a BlobBodyStreamHolder object, that gets corrupted:

```
326 CRASH--> NS_IMPL_CYCLE_COLLECTION_TRACE_BEGIN_INHERITED(BlobBodyStreamHolder,
                                               BodyStreamHolder)
  NS_IMPL_CYCLE_COLLECTION_TRACE_JS_MEMBER_CALLBACK(mStream)
NS_IMPL_CYCLE_COLLECTION_TRACE_END
```

The BlobBodyStreamHolder is held as a RefPtr by a BodyStream (mStreamHolder), which is in turn held by Blob, which himself is a Cycle Collector participant.

I assume, this nested situation leads to a situation, in which:

1. CycleCollector collects all potential objects in a vector
2. while looking on them, the Blob is evicted
3. This removes (obscure to the cycle collector) also the nested BlobBodyStreamHolder
4. which then the Cycle Collector wants to remove

As I am new to Cycle Collectors: Is it a foreseen usage, to nest those classes and to delete them through the owner rather than the Collector itself?
Revision 1 by
on 
The debug information just tells us, that we have a BlobBodyStreamHolder object, that gets corrupted:

```
326 CRASH--> NS_IMPL_CYCLE_COLLECTION_TRACE_BEGIN_INHERITED(BlobBodyStreamHolder,
                                               BodyStreamHolder)
  NS_IMPL_CYCLE_COLLECTION_TRACE_JS_MEMBER_CALLBACK(mStream)
NS_IMPL_CYCLE_COLLECTION_TRACE_END
```

The BlobBodyStreamHolder is held as a RefPtr by a BodyStream (mStreamHolder), which is in turn held by Blob, which itself is a Cycle Collector participant.

I assume, this nested situation leads to a situation, in which:

1. CycleCollector collects all potential objects in a vector
2. while looking on them, the Blob is evicted
3. This removes (obscure to the cycle collector) also the nested BlobBodyStreamHolder
4. which then the Cycle Collector wants to remove

As I am new to Cycle Collectors: Is it a foreseen usage, to nest those classes and to delete them through the owner rather than the Collector itself?
Revision 2 by
on 
The debug information just tells us, that we have a BlobBodyStreamHolder object, that gets corrupted:

```
326 CRASH--> NS_IMPL_CYCLE_COLLECTION_TRACE_BEGIN_INHERITED(BlobBodyStreamHolder,
                                               BodyStreamHolder)
  NS_IMPL_CYCLE_COLLECTION_TRACE_JS_MEMBER_CALLBACK(mStream)
NS_IMPL_CYCLE_COLLECTION_TRACE_END
```

The BlobBodyStreamHolder is held as a RefPtr by a BodyStream (mStreamHolder), which is in turn held by Blob, which itself is a Cycle Collector participant.

I assume, this nested situation leads to a situation, in which:

1. CycleCollector collects all potential objects in a vector
2. while looking on them, the Blob is evicted
3. This removes (obscure to the cycle collector) also the nested BlobBodyStreamHolder
4. which then the Cycle Collector wants to remove

As I am new to Cycle Collectors: Is it a foreseen usage, to nest those Cycle Collector participants _and_ to delete them through the owner rather than the Collector itself?
Revision 3 by
on 
The debug information just tells us, that we have a BlobBodyStreamHolder object, that gets corrupted:

```
326 CRASH--> NS_IMPL_CYCLE_COLLECTION_TRACE_BEGIN_INHERITED(BlobBodyStreamHolder,
                                               BodyStreamHolder)
  NS_IMPL_CYCLE_COLLECTION_TRACE_JS_MEMBER_CALLBACK(mStream)
NS_IMPL_CYCLE_COLLECTION_TRACE_END
```

The BlobBodyStreamHolder is held as a RefPtr by a BodyStream (mStreamHolder), which is in turn held by Blob, which itself is a Cycle Collector participant.

I assume, this nested situation leads to a situation, in which:

1. CycleCollector collects all potential objects in a vector
2. while looking on them, the Blob is evicted
3. This removes (obscure to the cycle collector) also the nested BlobBodyStreamHolder
4. which then the Cycle Collector wants to remove

As I am new to Cycle Collectors: Is it a foreseen usage, to nest those Cycle Collector participants *and* to delete them through the owner rather than the Collector itself?
Revision 4 by
on 
The debug information just tells us, that we have a BlobBodyStreamHolder object, that gets corrupted:

```
326 CRASH--> NS_IMPL_CYCLE_COLLECTION_TRACE_BEGIN_INHERITED(BlobBodyStreamHolder,
                                               BodyStreamHolder)
  NS_IMPL_CYCLE_COLLECTION_TRACE_JS_MEMBER_CALLBACK(mStream)
NS_IMPL_CYCLE_COLLECTION_TRACE_END
```

The BlobBodyStreamHolder is held as a RefPtr by a BodyStream (mStreamHolder), which is in turn held by Blob, which itself is a Cycle Collector participant.

I assume, this nested situation leads to a situation, in which:

1. CycleCollector collects all potential objects in a vector
2. while looking on them, the Blob is evicted
3. This removes (obscure to the cycle collector) also the nested BlobBodyStreamHolder
4. which then the Cycle Collector wants to remove

As I am new to Cycle Collectors: Is it a foreseen usage, to nest those Cycle Collector participants **and** to delete them through the owner rather than the Collector itself?
Revision 5 by
on 
The debug information just tells us, that we have a BlobBodyStreamHolder object, that gets corrupted:

```
326 CRASH--> NS_IMPL_CYCLE_COLLECTION_TRACE_BEGIN_INHERITED(BlobBodyStreamHolder,
                                               BodyStreamHolder)
  NS_IMPL_CYCLE_COLLECTION_TRACE_JS_MEMBER_CALLBACK(mStream)
NS_IMPL_CYCLE_COLLECTION_TRACE_END
```

The BlobBodyStreamHolder is held as a RefPtr by a BodyStream (mStreamHolder), which is in turn held by Blob, which itself is a Cycle Collector participant.

I assume, this nested situation leads to a situation, in which:

1. CycleCollector collects all potential objects in a vector
2. while looking on them, the Blob is evicted
3. This removes (obscure to the cycle collector) also the nested BlobBodyStreamHolder
4. which then the Cycle Collector wants to remove

As I am new to Cycle Collectors: Is it a foreseen usage, to nest those Cycle Collector participants **and** to delete them through the owner rather than leave deletion to the Collector itself?

Back to Bug 1577311 Comment 11