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

[Michael Stahl]

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.

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?

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

i don't think it's a good idea that the Linux developers introduce such
regressions and then our Windows developers have to find them; those poor
souls use Windows after all so they already have enough problems  :)

> Caolán knows more. See commit d1f6403c9ee3caf6b2e6babe5eb6b2ff62feaa9d
> and the history of the stuff it touches.

hmmm... but why hook this into --enable-debug, and not --enable-dbgutil?

AFAIK --enable-debug just enables symbols, and is otherwise intended to be
compatible with an ordinary build.

but a --enable-dbgutil is not binary-compatible with a normal build
anyway, which is why it has always used a different $OUTDIR (e.g. unxlngx6
vs. unxlngx6.pro).
this should prevent most of the accidental mixing scenarios, no?

of course what also needs to be prevented is linking against system
libraries that expose STL in their interface; a quick search found me
cppunit and graphite; the mozilla/nss stuff doesn't seem to expose STL.

i've just completed a build with the attached patch; the smoketest
immediately failed with this assertion:

> /usr/lib/gcc/x86_64-redhat-linux/4.6.0/../../../../include/c++/4.6.0/debug/safe_iterator.h:208:
>     error: attempt to dereference a singular iterator.
> 
> Objects involved in the operation:
> iterator "this" @ 0x0x7fa2b652b500 {
> type = N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPKN5boost10shared_ptrIN2sw4mark5IMarkEEENSt9__cxx19986vectorIS8_SaIS8_EEEEENSt7__debug6vectorIS8_SD_EEEE (constant iterator);
>   state = singular;
>   references sequence with type `NSt7__debug6vectorIN5boost10shared_ptrIN2sw4mark5IMarkEEESaIS6_EEE' @ 0x0x7fa2b652b500
> }
> 

this is the bookmark problem that Windows developers found yesterday.

running the subsequenttests yielded 2 more STL assertions in dbaccess,
which i've fixed now (one was caused by accidentally removing a line in a
merge conflict resolution):

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3c6d38fed033ba8b47af75a9b8712a4bd2c0ddec

http://cgit.freedesktop.org/libreoffice/core/commit/?id=f69eb5b70342cbb499dc9b99a5eb78e59eb2d416

now the subsequenttests run successfully for me.
so it seems to me that such a build is pretty reliable.

(configured with:
./autogen.sh --enable-build-unowinreg --enable-dbgutil)

regards,
 michael
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dbgutil_stl.patch
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20110915/e1715c0d/attachment.ksh>