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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux