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

[Louis Dionne via libcxx-dev]

> 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 <mailto: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.

Cheers,
Louis

> 
> Just to link up the two threads: I ran into this earlier this year.
> https://lists.llvm.org/pipermail/libcxx-dev/2021-May/001119.html <https://lists.llvm.org/pipermail/libcxx-dev/2021-May/001119.html>
> It is the reason at least one test in libcxx/test/ is marked "LIBCXX-DEBUG-FIXME". I don't have any ideas how to fix it, though.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20211110/417fc28e/attachment.html>