Re: [Libreoffice] Usefulness of --enable-dbgutil

On 14.09.2011 16:39, Tor Lillqvist wrote:
> Over the past month or so I have hacked, now and then, on making it
> possible to build master on Windows (i.e. with MSVC) with
> --enable-dbgutil, where --enable-dbgutil now means that the debugging
> C/C++ runtime is used (and _DEBUG is defined when compiling, which
> means that for much of the MSVC C++ library code in the headers more
> thorough debugging versions of methods are used).
>
> (If I understand correctly, in OOo --enable-dbgutil doesn't cause use
> of the debugging runtime; they seem to have abandoned that idea at
> some point. I didn't get the hint but still tried to...)

in OOo, --enable-dbgutil enables DBG_ASSERT and the STL debug mode,
linking against stlport_debug (on platforms where STLport is used).

probably it also enables other debug features such as MSVC debug
runtime, but i'm not familiar with windows so this is just a guess.

in any case these are very useful debugging features and IMHO developers
should use always --enable-dbgutil (except when profiling/benchmarking
of course :)

> Now then, when I run a LO built in such a way, I get unhandled
> exceptions (invalid pointer dereferences, use of uninitialised heap it
> seems, for instance) when doing some very basic things, like typing a
> single character into a fresh empty text document.

that sounds like a serious bug.

if the person who introduced this regression had used --enable-dbgutil
then they would have found it themselves.

> This is more than what I had hoped for. I had expected to at most
> catch some obvious heap corruption in some rare corner case thanks to
> using the debugging runtime.
>
> Debugging this is not easy, it crashes inside the (Microsoft) C++
> library (headers), in iterator related code, called by the mark code
> in sw. I don't understand the implementation details of the C++
> library or the sw code...

probably an invalid iterator.

take a look at the git log of relevant files to find out who to blame :)

> So I wonder, is this use of the debugging runtime pointless? Do we
> have anybody anyway that would 1) understand the code in some specific
> part of LO, in this case the mark stuff in Writer, 2) have a Windows
> build and debugging environment and be willing to work in it, and 3)
> understand the C++ library (the Microsoft implementation) well enough
> to see what is happening...

Bjoern wrote the current bookmark stuff in writer, so he should be able
to debug it.

if it is indeed an invalid iterator it should happen with GCC as well.

> Should I just give up and revert the changes to use _DEBUG and the
> debugging runtime? Or leave that there but don't try to actually use
> it any more?

if only everybody used --enable-dbgutil this wouldn't be a problem.

> --tml

regards,
 michael