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.gdbserver-concept
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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
