зеркало из https://github.com/mozilla/gecko-dev.git
d6f0453414
Running with XPCOM_MEM_LOG_CLASSES=nsStringBuffer triggers an assertion in refcount logging for nsFakeStringBuffers. These are given an initial refcount of 1, without calling NS_LOG_ADDREF. Then, AddRef() is called on these objects in StaticAtom::StaticAtom(), and we tell the refcount logging system about the fake buffer, and that it has a refcount of 0, triggering the assertion. The first part of the fix is to call NS_LOG_ADDREF for this initial refcount, in StaticAtom(). This first fix causes refcount logging to start reporting that the fake string buffers leak, when XPCOM_MEM_LOG_CLASSES is not set. This is because refcount logging is now getting told about these objects being AddRefed at 1, which it takes to mean that an object is created. To work around this issue, I add an array gFakeBuffers that contains every fake string buffer we create, and tell the refcount logging system that these objects are all being destroyed, when the atom table is being shut down. This could result in some bogosity if the fake buffers are "leaked" but hopefully this is still an improvement over the current state. MozReview-Commit-ID: 5AxoBYAlYRU --HG-- extra : rebase_source : ba0763cb494894918141774025db525cea9f9c75 |
||
|---|---|---|
| .. | ||
| base | ||
| build | ||
| components | ||
| doc | ||
| ds | ||
| glue | ||
| idl-parser | ||
| io | ||
| libxpt/xptcall | ||
| reflect | ||
| rust | ||
| string | ||
| system | ||
| tests | ||
| threads | ||
| typelib | ||
| windbgdlg | ||
| xpidl | ||
| moz.build | ||
| xpcom-config.h.in | ||
| xpcom-private.h.in | ||