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

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

enable libstdc++ debug mode with --enable-dbgutil

diff --git a/configure.in b/configure.in
index 20ece15..f49952f 100755
--- a/configure.in
+++ b/configure.in
@@ -2293,6 +2293,17 @@ if test -n "$enable_dbgutil" && test "$enable_dbgutil" != "no"; then
     PRODUCT=""
     PROFULLSWITCH=""
     AC_MSG_RESULT([yes])
+    # cppunit and graphite expose STL in public headers
+    if test "$with_system_cppunit" = "yes"; then
+        AC_MSG_ERROR([--with-system-cppunit conflicts with DBG_UTIL build])
+    else
+        with_system_cppunit=no
+    fi
+    if test "$with_system_graphite" = "yes"; then
+        AC_MSG_ERROR([--with-system-graphite conflicts with DBG_UTIL build])
+    else
+        with_system_graphite=no
+    fi
     if test $_os = WINNT -a \( "$enable_mozilla" = yes -o "$enable_build_mozilla" = yes \); then
         # We can't build against the Mozilla stuff if using _DEBUG, will get linking errors
         # See connectivity/drivers/mozab
diff --git a/cppunit/makefile.mk b/cppunit/makefile.mk
index 7fba665..c29ac62 100644
--- a/cppunit/makefile.mk
+++ b/cppunit/makefile.mk
@@ -119,6 +119,14 @@ MY_LIBS = -lm
 
 CONFIGURE_ACTION = ./configure
 
+# FIXME TODO not for all platforms, just unxgcc!
+.IF "$(COM)" == "GCC"
+.IF "$(PRODUCT)"!="full"
+# enable debug STL
+EXTRA_CDEFS += -D_GLIBCXX_DEBUG
+.ENDIF # !PRODUCT
+.ENDIF # GCC
+
 .IF "$(debug)"!=""
 DEBUGFLAG=-g
 .ENDIF
diff --git a/solenv/gbuild/platform/unxgcc.mk b/solenv/gbuild/platform/unxgcc.mk
index 362b378..851cc75 100644
--- a/solenv/gbuild/platform/unxgcc.mk
+++ b/solenv/gbuild/platform/unxgcc.mk
@@ -107,6 +107,13 @@ endif
 
 endif
 
+# enable debug STL
+ifeq ($(gb_PRODUCT),$(false))
+gb_COMPILERDEFS += \
+       -D_GLIBCXX_DEBUG \
+
+endif
+
 gb_CCVER := $(shell $(gb_CC) -dumpversion | $(gb_AWK) -F. -- '{ print $$1*10000+$$2*100+$$3 }')
 gb_StrictAliasingUnsafe := $(shell expr $(gb_CCVER) \< 40600)
 
diff --git a/solenv/inc/unxgcc.mk b/solenv/inc/unxgcc.mk
index 752de80..f34f12b 100644
--- a/solenv/inc/unxgcc.mk
+++ b/solenv/inc/unxgcc.mk
@@ -91,6 +91,11 @@ CFLAGSCXX+=-fvisibility-inlines-hidden
 CFLAGSCXX+=-std=c++0x -Wno-deprecated-declarations
 .ENDIF # "$(HAVE_CXX0X)" == "TRUE"
 
+.IF "$(PRODUCT)"!="full"
+# enable debug STL
+CFLAGSCXX += -D_GLIBCXX_DEBUG
+.ENDIF # !PRODUCT
+
 CFLAGS_CREATE_PCH=-x c++-header -I$(INCPCH) -DPRECOMPILED_HEADERS
 CFLAGS_USE_PCH=-I$(SLO)$/pch -DPRECOMPILED_HEADERS -Winvalid-pch
 CFLAGS_USE_EXCEPTIONS_PCH=-I$(SLO)$/pch_ex -DPRECOMPILED_HEADERS -Winvalid-pch