help needed to find a bug in zorba (or gcc 4.9)

Martin Gieseking martin.gieseking at
Tue Jun 10 19:47:55 UTC 2014

Am 10.06.2014 20:44, schrieb Jerry James:
> Here's the first problem pointed out by valgrind:
> - class Store (src/store/naive/store.h) has a public member "zstring theEmptyNs"
> - that object is set to a string that is also added to "StringPool
> *theNamespacePool" inside Store::init() (src/store/naive/store.cpp)
> - when the ZorbaImpl destructor runs on the singleton ZorbaImpl
> object, it starts this call chain:
>   o shutdownInternal(false)
>   o StoreManager::shutdownStore(&GENV_STORE)
>   o SimpleStore::shutdown(false)
>   o Store::shutdown(false)
> - Since theNamespacePool is non-NULL, we do this:
>   theEmptyNs.~zstring();
>   theXmlSchemaNs.~zstring();
>   delete theNamespacePool;
>   theNamespacePool = NULL;
> We deleted theEmptyNs ... but left it sitting in theNamespacePool.  So
> when theNamespacePool's destructor runs, it examines that string,
> leading to the crash.  The same thing happens with theXmlSchemaNs.
> The fix is to remove those strings from the StringPool instead of
> explicitly deallocating them, and then let the Store destructor
> actually delete the two strings, like so:


thank you for taking the time to look into the code and for tracking
down the first issue. However, it's the same one I already fixed with
patch 4 (zorba-namespace-pool.patch) present in the latest SRPM [1]
linked in my initial email. It has also been applied upstream already.

> Unfortunately, it appears that that is not the only bug.  Valgrind
> shows at least two more bugs, both also tied into SimpleStore and
> Store somehow, but I'm out of time to look at them.

Yes, the remaining bugs are hard to isolate. They always occur in
conjunction with the zstring/rstring objects. I just can't find the
location where the memory gets corrupted so that the access to their
data fields fail...

> Off topic: the check for unicode/coll.h (ZORBA_HAVE_COLL_H) is failing
> spuriously because CHECK_INCLUDE_FILES is used where
> CHECK_INCLUDE_FILE_CXX should be used.  One fix is to do this in
> %prep:
> # Fix detection of unicode/coll.h
> sed -i 's,\(CHECK_INCLUDE_FILE\)S\( ("unicode/coll.h"\),\1_CXX\2,'
> CMakeLists.txt

Also thank you for this hint. I'm going to add the fix the bug and
report it upstream.



More information about the devel mailing list