Bugzilla

This is an ancient crash we have never been able to figure out. With the inlining changes last year, there are a lot of junk frames showing up there.  A few changes would improve the signature:

Add some COMPtr things to the prefix list. Knowing that the destructor of a COMPtr is running is not really useful. We want to know who is running that destructor.
~nsCOMPtr: example: bp-be45dea0-52c0-4ce3-b4f6-98c920230723#tab-details
~nsCOMPtr_base: bp-c0a0387e-d40b-406f-bb44-7a34a0230719

SegmentImpl: this is an internal implementation detail, so we don't really want it in the signature. In the crashes I looked at, the non-impl one was in the stack, too.

SegmentedVector to the prefix list. This is a data structure, so I think it is still useful to have in the signature, but we want to know who the caller is.

Here's a crash that combines a bunch of these together: bp-46954e0a-21c6-4e2b-b39b-2f5350230717

This is an ancient crash we have never been able to figure out. With the inlining changes last year, there are a lot of junk frames showing up there.  A few changes would improve the signature:

Add some COMPtr things to the prefix list. Knowing that the destructor of a COMPtr is running is not really useful. We want to know who is running that destructor.
~nsCOMPtr: example: bp-be45dea0-52c0-4ce3-b4f6-98c920230723
~nsCOMPtr_base: bp-c0a0387e-d40b-406f-bb44-7a34a0230719

SegmentImpl: this is an internal implementation detail, so we don't really want it in the signature. In the crashes I looked at, the non-impl one was in the stack, too.

SegmentedVector to the prefix list. This is a data structure, so I think it is still useful to have in the signature, but we want to know who the caller is.

Here's a crash that combines a bunch of these together: bp-46954e0a-21c6-4e2b-b39b-2f5350230717