1283337 - Make MOZ_COUNT_CTOR/DTOR track the type name with template argument available

Status: NEW

(Core :: XPCOM, defect, P3)

Description

[Xidorn Quan [:xidorn] UTC+11]

Currently, for example, if we leak a nsTArray<SomeType>, we only know that a nsTArray_base is leaked, but don't know what the "SomeType" is here. Not knowing that makes diagnosing this kind of leakage very difficult.

Simply using macro like what we are doing now wouldn't work because macros are expanded before instantiation.

Some options are:
1. try to use GCC/Clang's __PRETTY_FUNCTION__ and MSVC's __FUNCSIG__ macro, which are expanded after template instantiation, but we would need to parse the string for the typename.
2. enable RTTI for debug build and use typeid(T).name() to get the name.

Comment 1

[Xidorn Quan [:xidorn] UTC+11]

Attachment: proof of concept for MSVC

This is a proof of concept of including template arguments in leakcheck which works on MSVC. I wrote this for diagnosing bug 1283106.

Theoretically, something similiar can be done for GCC and Clang as well, I guess.

It may also be possible to make the type name be parsed at compile time rather than runtime, so that it wouldn't slow down tests, but I haven't figured out how.

Comment 2

[Xidorn Quan [:xidorn] UTC+11]

Another option:
wait for compile time reflection: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0385r0

Comment 3

[Xidorn Quan [:xidorn] UTC+11]

Attachment: proof of concept for MSVC

Comment 4

[Nathan Froyd [:froydnj]]

Comment on attachment 8767554 [details] [diff] [review]
proof of concept for MSVC

Review of attachment 8767554 [details] [diff] [review]:
-----------------------------------------------------------------

The RTTI approach strikes me as a better way to do things--more portable, more robust, more comprehensible, and probably more performant.

Comment 5

[Simon Giesecke [:sg] [he/him]]

What about using https://github.com/adambadura/type_name as an existing wrapper for the PRETTY_FUNCTION based approach? I think RTTI without a wrapper doesn't yield portable results either, and there doesn't seem to have been progress on enabling RTTI in debug builds in the last years?

Comment 6

[Nika Layzell [:nika] (ni? for response)]

FWIW, it appears as though the minimum-supported gcc version for that crate is gcc 7.3 (https://github.com/adambadura/type_name/blob/eceef6604197afbca2595526b2f86f19cb80c60b/include/type_name/type_name.gcc.hpp#L9), and according to https://firefox-source-docs.mozilla.org/code-quality/coding-style/using_cxx_in_firefox_code.html, we support as low as gcc 7.1.

Comment 7

[Simon Giesecke [:sg] [he/him]]

That's right, but I don't know if we need that to actually work on gcc builds? It needs to build somehow, of course.