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...) 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. 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... 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... 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? --tml _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
