On 10.6.2014 21:47, Martin Gieseking wrote:
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:
Jerry,
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...
Maybe you can try Valgrind & gdbserver:
http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbs...
I'm sorry if you already tried that :-)
Petr^2 Spacek
> 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.
Martin
[1]
http://mgieseki.fedorapeople.org/review/zorba-3.0.0-4.fc21.src.rpm