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]

 



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...


> 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