[Libreoffice] [PATCH] libstdc++ STL debug (was: Re: Usefulness of --enable-dbgutil)

[Lubos Lunak]

On Thursday 15 of September 2011, Michael Stahl wrote:
> On 14.09.2011 20:50, Tor Lillqvist wrote:
> >> but currently LO doesn't seem to use it (couldn't find
> >> -D_GLIBCXX_DEBUG); why is that?
> >
> > We tried, but we ran into so many problems when code compiled with
> > that without that were mixed (accidentally/unintentionally) that we
> > gave up.
>
> hmmm... guess mixing these could cause problems.

 Could and did. See 
http://lists.freedesktop.org/archives/libreoffice/2011-July/014970.html for 
the discussion that eventually lead to the removal of the STL debug support.

> but the documentation says that the debug stuff is in a different
> namespace, so trying to call a function in a linked library with a
> parameter of the wrong debug-ness should fail to link?

 It should, at least the mangling really is different, but not all problems 
can be detected at link time. Suppose you have class A, which has std::list 
as a member, and you pass along only A*. In that case linker only sees A*, 
not std::list, so it cannot detect the mismatch. Similarly the compiler will 
not see any mismatch, only code compiled with and without debug support will 
use different layout of A, leading to memory corruptions.

 We would need a way to ensure that any C++ library we use is built with STL 
debug mode, or that it does not pass any STL objects across .so boundaries 
(and I intentionally say .so and not library, because e.g. inlines may end up 
in a different .so than the library they belong to).

> for STLport this was apparently solved by using a distinct library for the
> debug mode.

 Oh well, I think we've already agreed here that the libstdc++ debug mode 
implementation is ... not very good.

> i don't think it's a good idea that the Linux developers introduce such
> regressions

 Agreed, but Linux developers getting mysterious crashes is not a very good 
idea either, so it is a question if STL debug mode is worth it.

-- 
 Lubos Lunak
 l.lunak at suse.cz