[libcxx-dev] Building a program with -D_LIBCPP_DEBUG=1 against a libc++ that is not itself built with that define

[Hans Wennborg via libcxx-dev]

On Wed, Nov 10, 2021 at 9:56 PM Louis Dionne via libcxx-dev
<libcxx-dev at lists.llvm.org> wrote:
>
>
>
> On Oct 29, 2021, at 11:29, Arthur O'Dwyer via libcxx-dev <libcxx-dev at lists.llvm.org> wrote:
>
> On Fri, Oct 29, 2021 at 9:09 AM Stephan Bergmann via libcxx-dev <libcxx-dev at lists.llvm.org> wrote:
>>
>> At least with recent LLVM 14 trunk,
>> [...]
>> > Segmentation fault
>> [...]
>> because the std::string instance returned from std::to_string
>> (implemented in libc++, not itself built with -D_LIBCPP_DEBUG=1) never
>> called __libcpp_db::__insert_c(this), so __libcpp_db::swap doesn't find
>> it in the __cbeg_/__cend_ table and then dereferences a null pointer.
>>
>> I wonder how usable and mature -D_LIBCPP_DEBUG=1 is considered in
>> practice.  Is this a well-known shortcoming (in which case it might be
>> good to mention it explicitly in libcxx/docs/DesignDocs/DebugMode.rst,
>> beyond just "Users should compile their whole program at the same
>> debugging level."), or would it be worth filing a bug?
>
>
> On the maturity level: libc++'s debugging mode is quite broken at the moment, however it is on my high priority list of things to fix.
> That being said, even after it is fixed, you will *not* be able to just `#define _LIBCPP_DEBUG 1` in your own translation unit.
> You will need to use a libc++ that has been built for the debug mode in order for things to work.
>
> However, once I'm done fixing the mess, you should be able to use something akin to #define _LIBCPP_ENABLE_ASSERTIONS
> to get most non-ABI-or-performance-altering assertions enabled in just your TU. Things such as assertions if you index a
> vector beyond its bounds.

That sounds like a good plan. Something like _LIBCPP_ENABLE_ASSERTIONS
would potentially be very interesting for Chromium.

Thanks,
Hans