Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1095292 - zorba fails to build with gcc 4.9.0
Summary: zorba fails to build with gcc 4.9.0
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: zorba
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Martin Gieseking
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1106712 (view as bug list)
Depends On:
Blocks: F21FTBFS
TreeView+ depends on / blocked
 
Reported: 2014-05-07 12:22 UTC by Martin Gieseking
Modified: 2014-06-22 16:19 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-22 16:19:37 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1317976 0 None None None Never

Description Martin Gieseking 2014-05-07 12:22:49 UTC 
The zorba package fails to build for rawhide using the current gcc 4.9.0 because the binary segfaults while creating additional documentation files. The same package builds correctly for f20 (using gcc 4.8.2). It seems that this is a regression in the optimizer since the issue only appears when building with -O1, -O2, or -O3. An "unoptimized build" (-O0) succeeds. The build also succeeds when applying only one of the optimization options involved in -O1. I didn't try all permutations (yet).

Here is a scratch build for i686:
http://koji.fedoraproject.org/koji/taskinfo?taskID=6819502

The resulting binary crashes when it's called with any query, e.g. the following which should just print "1" (plus the XML declaration):

$ zorba -q 1

<?xml version="1.0" encoding="UTF-8"?>

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff3292f09 in malloc_consolidate () from /lib64/libc.so.6

#0  0x00007ffff3292f09 in malloc_consolidate () from /lib64/libc.so.6
#1  0x00007ffff3294328 in _int_free () from /lib64/libc.so.6
#2  0x00007ffff3298d8c in free () from /lib64/libc.so.6
#3  0x00007ffff763837f in deallocate (this=<optimized out>, __p=<optimized out>) at /usr/include/c++/4.9.0/ext/new_allocator.h:110
#4  deallocate (__a=..., __n=<optimized out>, __p=<optimized out>) at /usr/include/c++/4.9.0/ext/alloc_traits.h:185
#5  _M_deallocate (this=<optimized out>, __n=<optimized out>, __p=<optimized out>) at /usr/include/c++/4.9.0/bits/stl_vector.h:178
#6  ~_Vector_base (this=0x61a508, __in_chrg=<optimized out>) at /usr/include/c++/4.9.0/bits/stl_vector.h:160
#7  ~vector (this=0x61a508, __in_chrg=<optimized out>) at /usr/include/c++/4.9.0/bits/stl_vector.h:425
#8  ~HashMap (this=0x61a500, __in_chrg=<optimized out>) at /builddir/build/BUILD/zorba-3.0/src/zorbautils/hashmap.h:496
#9  ~HashMap (this=0x61a500, __in_chrg=<optimized out>) at /builddir/build/BUILD/zorba-3.0/src/zorbautils/hashmap.h:496
#10 zorba::serialization::Archiver::~Archiver (this=0x61a320, __in_chrg=<optimized out>)
    at /builddir/build/BUILD/zorba-3.0/src/zorbaserialization/archiver.cpp:272
#11 0x00007ffff763b7fb in ~MemArchiver (this=0x61a320, __in_chrg=<optimized out>)
    at /builddir/build/BUILD/zorba-3.0/src/zorbaserialization/mem_archiver.h:30
#12 zorba::serialization::MemArchiver::~MemArchiver (this=0x61a320, __in_chrg=<optimized out>)
    at /builddir/build/BUILD/zorba-3.0/src/zorbaserialization/mem_archiver.h:30
#13 0x00007ffff7637488 in zorba::serialization::ClassSerializer::~ClassSerializer (
    this=0x7ffff7dd75e0 <zorba::serialization::ClassSerializer::getInstance()::theInstance>, __in_chrg=<optimized out>)
    at /builddir/build/BUILD/zorba-3.0/src/zorbaserialization/class_serializer.cpp:68
#14 0x00007ffff324ca6a in __cxa_finalize () from /lib64/libc.so.6
#15 0x00007ffff6f78f33 in __do_global_dtors_aux () from /builddir/build/BUILD/zorba-3.0/build/src/libzorba_simplestore.so.3.0.0
#16 0x00007fffffffe510 in ?? ()
#17 0x00007ffff7dea0d7 in _dl_fini () from /lib64/ld-linux-x86-64.so.2
Comment 1 Martin Gieseking 2014-05-07 18:28:42 UTC 
The issue seems to be related to bug 1094975.
Comment 2 Mamoru TASAKA 2014-05-08 08:45:27 UTC 
With adding -fsanitize=address -fsanitize=undefined

example-name [1]: excel_subtotal9.xq
example-name [1]: excel_subtotal10.xq
example-name [1]: excel_subtotal11.xq
=================================================================
==3557==ERROR: AddressSanitizer: heap-use-after-free on address 0x6060005952e0 at pc 0x7fe51648ea07 bp 0x7fff6ada5560 sp 0x7fff6ada5550
WRITE of size 4 at 0x6060005952e0 thread T0
    #0 0x7fe51648ea06 in __exchange_and_add /usr/include/c++/4.9.0/ext/atomicity.h:49
    #1 0x7fe51648ea06 in zorba::atomic_int::pre_dec() /builddir/build/BUILD/zorba-3.0/src/util/atomic_int.h:228
    #2 0x7fe51648ea06 in zorba::atomic_int::operator--() /builddir/build/BUILD/zorba-3.0/src/util/atomic_int.h:136
    #3 0x7fe51648ea06 in zorba::rstring_classes::rep_base<zorba::atomic_int, std::char_traits<char>, std::allocator<char> >::dec() /builddir/build/BUILD/zorba-3.0/src/util/string/rep_base.h:187
    #4 0x7fe51648ea06 in zorba::rstring_classes::rep<zorba::atomic_int, std::char_traits<char>, std::allocator<char> >::dispose(std::allocator<char> const&) /builddir/build/BUILD/zorba-3.0/src/util/string/default_rep.h:135
    #5 0x7fe51648ea06 in zorba::rstring_classes::rep_proxy<zorba::rstring_classes::rep<zorba::atomic_int, std::char_traits<char>, std::allocator<char> > >::dispose(std::allocator<char> const&) /builddir/build/BUILD/zorba-3.0/src/util/string/rep_proxy.h:76
    #6 0x7fe51648ea06 in ~rstring /builddir/build/BUILD/zorba-3.0/src/util/string/rstring.h:252
    #7 0x7fe51648ea06 in ~AnyUriItem /builddir/build/BUILD/zorba-3.0/src/store/naive/atomic_items.h:600
    #8 0x7fe51648ea06 in zorba::simplestore::AnyUriItem::~AnyUriItem() /builddir/build/BUILD/zorba-3.0/src/store/naive/atomic_items.h:600
    #9 0x7fe51659053e in ~ItemHandle /builddir/build/BUILD/zorba-3.0/src/store/api/item_handle.h:62
    #10 0x7fe51659053e in ~AttributeNode /builddir/build/BUILD/zorba-3.0/src/store/naive/node_items.h:1207
    #11 0x7fe51659053e in zorba::simplestore::AttributeNode::~AttributeNode() /builddir/build/BUILD/zorba-3.0/src/store/naive/node_items.h:1207
    #12 0x7fe5165733c9 in zorba::simplestore::XmlNode::destroyInternal(bool) /builddir/build/BUILD/zorba-3.0/src/store/naive/node_items.cpp:927
    #13 0x7fe5165738c6 in zorba::simplestore::XmlNode::destroyInternal(bool) /builddir/build/BUILD/zorba-3.0/src/store/naive/node_items.cpp:902
    #14 0x7fe516573680 in zorba::simplestore::XmlNode::destroyInternal(bool) /builddir/build/BUILD/zorba-3.0/src/store/naive/node_items.cpp:893
    #15 0x7fe516573680 in zorba::simplestore::XmlNode::destroyInternal(bool) /builddir/build/BUILD/zorba-3.0/src/store/naive/node_items.cpp:893
    #16 0x7fe516573680 in zorba::simplestore::XmlNode::destroyInternal(bool) /builddir/build/BUILD/zorba-3.0/src/store/naive/node_items.cpp:893
    #17 0x7fe516573680 in zorba::simplestore::XmlNode::destroyInternal(bool) /builddir/build/BUILD/zorba-3.0/src/store/naive/node_items.cpp:893
    #18 0x7fe516573680 in zorba::simplestore::XmlNode::destroyInternal(bool) /builddir/build/BUILD/zorba-3.0/src/store/naive/node_items.cpp:893
    #19 0x7fe516573d39 in zorba::simplestore::XmlNode::destroy(bool) /builddir/build/BUILD/zorba-3.0/src/store/naive/node_items.cpp:861
    #20 0x7fe516573fad in zorba::simplestore::XmlTree::destroy() /builddir/build/BUILD/zorba-3.0/src/store/naive/node_items.cpp:122
    #21 0x7fe51590d169 in zorba::flwor::FLWORIterator::bindVariable(unsigned long, zorba::flwor::FlworState*, zorba::PlanState&) const /builddir/build/BUILD/zorba-3.0/src/runtime/core/flwor_iterator.cpp:1233
    #22 0x7fe51592259f in zorba::flwor::FLWORIterator::nextImpl(zorba::store::ItemHandle<zorba::store::Item>&, zorba::PlanState&) const /builddir/build/BUILD/zorba-3.0/src/runtime/core/flwor_iterator.cpp:970
    #23 0x7fe5159aef41 in zorba::PlanIterator::produceNext(zorba::store::ItemHandle<zorba::store::Item>&, zorba::PlanState&) const /builddir/build/BUILD/zorba-3.0/src/runtime/base/plan_iterator.h:433
    #24 0x7fe5159aef41 in zorba::PlanIterator::consumeNext(zorba::store::ItemHandle<zorba::store::Item>&, zorba::PlanIterator const*, zorba::PlanState&) /builddir/build/BUILD/zorba-3.0/src/runtime/base/plan_iterator.h:459
    #25 0x7fe5159aef41 in zorba::ChildAxisIterator::nextImpl(zorba::store::ItemHandle<zorba::store::Item>&, zorba::PlanState&) const /builddir/build/BUILD/zorba-3.0/src/runtime/core/path_iterators.cpp:1143
    #26 0x7fe5165b02f0 in zorba::simplestore::StoreNodeDistinctIterator::next(zorba::store::ItemHandle<zorba::store::Item>&) /builddir/build/BUILD/zorba-3.0/src/store/naive/node_iterators.cpp:158
    #27 0x7fe51590d06e in zorba::flwor::FLWORIterator::bindVariable(unsigned long, zorba::flwor::FlworState*, zorba::PlanState&) const /builddir/build/BUILD/zorba-3.0/src/runtime/core/flwor_iterator.cpp:1221
    #28 0x7fe51592259f in zorba::flwor::FLWORIterator::nextImpl(zorba::store::ItemHandle<zorba::store::Item>&, zorba::PlanState&) const /builddir/build/BUILD/zorba-3.0/src/runtime/core/flwor_iterator.cpp:970
    #29 0x7fe515921dae in zorba::flwor::FLWORIterator::nextImpl(zorba::store::ItemHandle<zorba::store::Item>&, zorba::PlanState&) const /builddir/build/BUILD/zorba-3.0/src/runtime/core/flwor_iterator.cpp:1049
    #30 0x7fe515d13ba9 in zorba::PlanIterator::produceNext(zorba::store::ItemHandle<zorba::store::Item>&, zorba::PlanState&) const /builddir/build/BUILD/zorba-3.0/src/runtime/base/plan_iterator.h:433
    #31 0x7fe515d13ba9 in zorba::PlanIterator::consumeNext(zorba::store::ItemHandle<zorba::store::Item>&, zorba::PlanIterator const*, zorba::PlanState&) /builddir/build/BUILD/zorba-3.0/src/runtime/base/plan_iterator.h:459
    #32 0x7fe515d13ba9 in zorba::SequentialIterator::nextImpl(zorba::store::ItemHandle<zorba::store::Item>&, zorba::PlanState&) const /builddir/build/BUILD/zorba-3.0/src/runtime/scripting/scripting.cpp:96
    #33 0x7fe515d13ba9 in zorba::PlanIterator::produceNext(zorba::store::ItemHandle<zorba::store::Item>&, zorba::PlanState&) const /builddir/build/BUILD/zorba-3.0/src/runtime/base/plan_iterator.h:433
    #34 0x7fe515d13ba9 in zorba::PlanIterator::consumeNext(zorba::store::ItemHandle<zorba::store::Item>&, zorba::PlanIterator const*, zorba::PlanState&) /builddir/build/BUILD/zorba-3.0/src/runtime/base/plan_iterator.h:459
    #35 0x7fe515d13ba9 in zorba::SequentialIterator::nextImpl(zorba::store::ItemHandle<zorba::store::Item>&, zorba::PlanState&) const /builddir/build/BUILD/zorba-3.0/src/runtime/scripting/scripting.cpp:96
    #36 0x7fe51583a403 in zorba::PlanIterator::produceNext(zorba::store::ItemHandle<zorba::store::Item>&, zorba::PlanState&) const /builddir/build/BUILD/zorba-3.0/src/runtime/base/plan_iterator.h:433
    #37 0x7fe51583a403 in zorba::PlanIterator::consumeNext(zorba::store::ItemHandle<zorba::store::Item>&, zorba::PlanIterator const*, zorba::PlanState&) /builddir/build/BUILD/zorba-3.0/src/runtime/base/plan_iterator.h:459
    #38 0x7fe51583a403 in zorba::PlanWrapper::next(zorba::store::ItemHandle<zorba::store::Item>&) /builddir/build/BUILD/zorba-3.0/src/runtime/api/plan_wrapper.cpp:151
    #39 0x7fe513fac11c in zorba::serializer::serialize(zorba::rchandle<zorba::store::Iterator>, std::ostream&, zorba::SAX2_ContentHandler*, bool) /builddir/build/BUILD/zorba-3.0/src/api/serialization/serializer.cpp:2696
    #40 0x7fe513fad9b8 in zorba::serializer::serialize(zorba::rchandle<zorba::store::Iterator>, std::ostream&, bool) /builddir/build/BUILD/zorba-3.0/src/api/serialization/serializer.cpp:2647
    #41 0x7fe513e37948 in zorba::XQueryImpl::serialize(std::ostream&, zorba::rchandle<zorba::PlanWrapper>&, Zorba_SerializerOptions const*) /builddir/build/BUILD/zorba-3.0/src/api/xqueryimpl.cpp:1324
    #42 0x7fe513e37f20 in zorba::XQueryImpl::execute(std::ostream&, Zorba_SerializerOptions const*) /builddir/build/BUILD/zorba-3.0/src/api/xqueryimpl.cpp:1150
    #43 0x4180db in compileAndExecute(zorba::Zorba*, zorba::XmlDataManager*, ZorbaCMDProperties const&, zorba::SmartPtr<zorba::StaticContext>&, std::string const&, std::istream&, std::ostream&, TimingInfo&) /builddir/build/BUILD/zorba-3.0/bin/zorbacmd.cpp:871
    #44 0x408a5b in main /builddir/build/BUILD/zorba-3.0/bin/zorbacmd.cpp:1204
    #45 0x7fe50a3e80bf in __libc_start_main (/lib64/libc.so.6+0x200bf)
    #46 0x40cfa6 (/builddir/build/BUILD/zorba-3.0/build/bin/zorba+0x40cfa6)
0x6060005952e0 is located 0 bytes inside of 49-byte region [0x6060005952e0,0x606000595311)
freed by thread T0 here:
    #0 0x7fe51d0fba1f in operator delete(void*) (/lib64/libasan.so.1+0x58a1f)
    #1 0x7fe51648e9fc in __gnu_cxx::new_allocator<char>::deallocate(char*, unsigned long) /usr/include/c++/4.9.0/ext/new_allocator.h:110
    #2 0x7fe51648e9fc in zorba::rstring_classes::rep<zorba::atomic_int, std::char_traits<char>, std::allocator<char> >::dispose(std::allocator<char> const&) /builddir/build/BUILD/zorba-3.0/src/util/string/default_rep.h:136
    #3 0x7fe51648e9fc in zorba::rstring_classes::rep_proxy<zorba::rstring_classes::rep<zorba::atomic_int, std::char_traits<char>, std::allocator<char> > >::dispose(std::allocator<char> const&) /builddir/build/BUILD/zorba-3.0/src/util/string/rep_proxy.h:76
    #4 0x7fe51648e9fc in ~rstring /builddir/build/BUILD/zorba-3.0/src/util/string/rstring.h:252
    #5 0x7fe51648e9fc in ~AnyUriItem /builddir/build/BUILD/zorba-3.0/src/store/naive/atomic_items.h:600
    #6 0x7fe51648e9fc in zorba::simplestore::AnyUriItem::~AnyUriItem() /builddir/build/BUILD/zorba-3.0/src/store/naive/atomic_items.h:600
previously allocated by thread T0 here:
    #0 0x7fe51d0fb51f in operator new(unsigned long) (/lib64/libasan.so.1+0x5851f)
    #1 0x7fe513e6cd40 in __gnu_cxx::new_allocator<char>::allocate(unsigned long, void const*) /usr/include/c++/4.9.0/ext/new_allocator.h:104
    #2 0x7fe513e6cd40 in zorba::rstring_classes::rep<zorba::atomic_int, std::char_traits<char>, std::allocator<char> >::alloc(std::allocator<char> const&, unsigned long, unsigned long) /builddir/build/BUILD/zorba-3.0/src/util/string/default_rep.tcc:45
SUMMARY: AddressSanitizer: heap-use-after-free /usr/include/c++/4.9.0/ext/atomicity.h:49 __exchange_and_add
Shadow bytes around the buggy address:
  0x0c0c800aaa00: fd fd fd fd fa fa fa fa fd fd fd fd fd fd fd fd
  0x0c0c800aaa10: fa fa fa fa fd fd fd fd fd fd fd fd fa fa fa fa
  0x0c0c800aaa20: fd fd fd fd fd fd fd fa fa fa fa fa fd fd fd fd
  0x0c0c800aaa30: fd fd fd fa fa fa fa fa fd fd fd fd fd fd fd fa
  0x0c0c800aaa40: fa fa fa fa fd fd fd fd fd fd fd fd fa fa fa fa
=>0x0c0c800aaa50: fd fd fd fd fd fd fd fd fa fa fa fa[fd]fd fd fd
  0x0c0c800aaa60: fd fd fd fa fa fa fa fa fd fd fd fd fd fd fd fa
  0x0c0c800aaa70: fa fa fa fa fd fd fd fd fd fd fd fa fa fa fa fa
  0x0c0c800aaa80: 00 00 00 00 00 00 00 07 fa fa fa fa fd fd fd fd
  0x0c0c800aaa90: fd fd fd fa fa fa fa fa fd fd fd fd fd fd fd fa
  0x0c0c800aaaa0: fa fa fa fa fd fd fd fd fd fd fd fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Contiguous container OOB:fc
  ASan internal:           fe
==3557==ABORTING
make[3]: Leaving directory `/builddir/build/BUILD/zorba-3.0/build'
make[2]: Leaving directory `/builddir/build/BUILD/zorba-3.0/build'
make[3]: *** [CMakeFiles/xqdoc] Error 1
make[2]: *** [CMakeFiles/xqdoc.dir/all] Error 2
make[1]: *** [doc/CMakeFiles/doc.dir/rule] Error 2
make[1]: Leaving directory `/builddir/build/BUILD/zorba-3.0/build'
make: *** [doc] Error 2
Comment 3 Frank Ch. Eigler 2014-05-08 22:57:01 UTC 
Please run your program under valgrind, with whatever gcc and whatever optimization level you believe work, before you assume new gcc -O* is at fault.
Comment 4 Martin Gieseking 2014-05-09 09:46:45 UTC 
Frank, I actually did that but rawhide's valgrind doesn't seem to be helpful here. It reports a segmentation fault or an illegal instruction no matter what program is analyzed. Even a simple "hello world" program segfaults if it's called with valgrind.

Here's the output of the unoptimized zorba binary called without any parameters:

$ valgrind -v zorba

==564== Memcheck, a memory error detector
==564== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==564== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==564== Command: ./zorba
==564== 
--564-- Valgrind options:
--564--    -v
--564-- Contents of /proc/version:
--564--   Linux version 3.14.2-200.fc20.x86_64 (mockbuild.fedoraproject.org) (gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC) ) #1 SMP Mon Apr 28 14:40:57 UTC 2014
--564-- Arch and hwcaps: AMD64, amd64-cx16-rdtscp-sse3-avx
--564-- Page sizes: currently 4096, max supported 4096
--564-- Valgrind library directory: /usr/lib64/valgrind
--564-- Reading syms from /builddir/build/BUILD/zorba-3.0/build/bin/zorba
--564-- Reading syms from /usr/lib64/ld-2.19.90.so
--564-- Reading syms from /usr/lib64/valgrind/memcheck-amd64-linux
--564--    object doesn't have a symbol table
--564--    object doesn't have a dynamic symbol table
--564-- Scheduler: using generic scheduler lock implementation.
--564-- Reading suppressions file: /usr/lib64/valgrind/default.supp
==564== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-564-by-root-on-localhost.localdomain
==564== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-564-by-root-on-localhost.localdomain
==564== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-564-by-root-on-localhost.localdomain
==564== 
==564== TO CONTROL THIS PROCESS USING vgdb (which you probably
==564== don't want to do, unless you know exactly what you're doing,
==564== or are doing some strange experiment):
==564==   /usr/lib64/valgrind/../../bin/vgdb --pid=564 ...command...
==564== 
==564== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==564==   /path/to/gdb ./zorba
==564== and then give GDB the following command
==564==   target remote | /usr/lib64/valgrind/../../bin/vgdb --pid=564
==564== --pid is optional if only one valgrind process is running
==564== 
--564-- REDIR: 0x401b130 (strlen) redirected to 0x38067a21 (???)
--564-- Reading syms from /usr/lib64/valgrind/vgpreload_core-amd64-linux.so
--564--    object doesn't have a symbol table
--564-- Reading syms from /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so
--564--    object doesn't have a symbol table
==564== WARNING: new redirection conflicts with existing -- ignoring it
--564--     old: 0x0401b130 (strlen              ) R-> (0000.0) 0x38067a21 ???
--564--     new: 0x0401b130 (strlen              ) R-> (2007.0) 0x04c2ec20 strlen
--564-- REDIR: 0x401aee0 (index) redirected to 0x4c2e7d0 (index)
--564-- REDIR: 0x401b100 (strcmp) redirected to 0x4c2fd70 (strcmp)
--564-- REDIR: 0x401be20 (mempcpy) redirected to 0x4c32820 (mempcpy)
--564-- Reading syms from /builddir/build/BUILD/zorba-3.0/build/src/libzorba_simplestore.so.3.0.0
--564-- Reading syms from /usr/lib64/libpthread-2.19.90.so
--564-- Reading syms from /usr/lib64/librt-2.19.90.so
--564-- Reading syms from /usr/lib64/libicuuc.so.52.1
--564--    object doesn't have a symbol table
--564-- Reading syms from /usr/lib64/libicui18n.so.52.1
--564--    object doesn't have a symbol table
--564-- Reading syms from /usr/lib64/libicudata.so.52.1
--564--    object doesn't have a symbol table
--564-- Reading syms from /usr/lib64/libxml2.so.2.9.1
--564--    object doesn't have a symbol table
--564-- Reading syms from /usr/lib64/libuuid.so.1.3.0
--564--    object doesn't have a symbol table
--564-- Reading syms from /usr/lib64/libxerces-c-3.1.so
--564--    object doesn't have a symbol table
--564-- Reading syms from /usr/lib64/libstdc++.so.6.0.20
--564--    object doesn't have a symbol table
--564-- Reading syms from /usr/lib64/libm-2.19.90.so
--564-- Reading syms from /usr/lib64/libgcc_s-4.9.0-20140506.so.1
--564--    object doesn't have a symbol table
--564-- Reading syms from /usr/lib64/libc-2.19.90.so
--564-- Reading syms from /usr/lib64/libdl-2.19.90.so
--564-- Reading syms from /usr/lib64/libz.so.1.2.8
--564--    object doesn't have a symbol table
--564-- Reading syms from /usr/lib64/liblzma.so.5.0.99
--564--    object doesn't have a symbol table
--564-- Reading syms from /usr/lib64/libnsl-2.19.90.so
--564-- REDIR: 0x9b54460 (memcpy@@GLIBC_2.14) redirected to 0x4a26713 (_vgnU_ifunc_wrapper)
--564-- REDIR: 0x9b4fa90 (strcasecmp) redirected to 0x4a26713 (_vgnU_ifunc_wrapper)
--564-- REDIR: 0x9b51d80 (strncasecmp) redirected to 0x4a26713 (_vgnU_ifunc_wrapper)
--564-- REDIR: 0x9b4f260 (memcpy.5) redirected to 0x4a26713 (_vgnU_ifunc_wrapper)
vex amd64->IR: unhandled instruction bytes: 0x66 0xF 0x1B 0x4 0x24 0x66 0xF 0x1B
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F
vex amd64->IR:   PFX.66=1 PFX.F2=0 PFX.F3=0
==564== valgrind: Unrecognised instruction at address 0x40173b7.
==564==    at 0x40173B7: _dl_runtime_resolve (in /usr/lib64/ld-2.19.90.so)
==564==    by 0x95AEA98: __exp_finite (in /usr/lib64/libm-2.19.90.so)
==564==    by 0x400CB5E: _dl_relocate_object (in /usr/lib64/ld-2.19.90.so)
==564==    by 0x4003BB1: dl_main (in /usr/lib64/ld-2.19.90.so)
==564==    by 0x4018994: _dl_sysdep_start (in /usr/lib64/ld-2.19.90.so)
==564==    by 0x4004F17: _dl_start (in /usr/lib64/ld-2.19.90.so)
==564==    by 0x4000D47: ??? (in /usr/lib64/ld-2.19.90.so)
==564== Your program just tried to execute an instruction that Valgrind
==564== did not recognise.  There are two possible reasons for this.
==564== 1. Your program has a bug and erroneously jumped to a non-code
==564==    location.  If you are running Memcheck and you just saw a
==564==    warning about a bad jump, it's probably your program's fault.
==564== 2. The instruction is legitimate but Valgrind doesn't handle it,
==564==    i.e. it's Valgrind's fault.  If you think this is the case or
==564==    you are not sure, please let us know and we'll try to fix it.
==564== Either way, Valgrind will now raise a SIGILL signal which will
==564== probably kill your program.
==564== 
==564== Process terminating with default action of signal 4 (SIGILL)
==564==  Illegal opcode at address 0x40173B7
==564==    at 0x40173B7: _dl_runtime_resolve (in /usr/lib64/ld-2.19.90.so)
==564==    by 0x95AEA98: __exp_finite (in /usr/lib64/libm-2.19.90.so)
==564==    by 0x400CB5E: _dl_relocate_object (in /usr/lib64/ld-2.19.90.so)
==564==    by 0x4003BB1: dl_main (in /usr/lib64/ld-2.19.90.so)
==564==    by 0x4018994: _dl_sysdep_start (in /usr/lib64/ld-2.19.90.so)
==564==    by 0x4004F17: _dl_start (in /usr/lib64/ld-2.19.90.so)
==564==    by 0x4000D47: ??? (in /usr/lib64/ld-2.19.90.so)
==564== Jump to the invalid address stated on the next line
==564==    at 0x5A6: ???
==564==    by 0xFFF00023F: ???
==564==    by 0x4003BB1: dl_main (in /usr/lib64/ld-2.19.90.so)
==564==    by 0x4018994: _dl_sysdep_start (in /usr/lib64/ld-2.19.90.so)
==564==    by 0x4004F17: _dl_start (in /usr/lib64/ld-2.19.90.so)
==564==    by 0x4000D47: ??? (in /usr/lib64/ld-2.19.90.so)
==564==  Address 0x5a6 is not stack'd, malloc'd or (recently) free'd
==564== 
==564== 
==564== Process terminating with default action of signal 11 (SIGSEGV)
==564==  Bad permissions for mapped region at address 0x5A6
==564==    at 0x5A6: ???
==564==    by 0xFFF00023F: ???
==564==    by 0x4003BB1: dl_main (in /usr/lib64/ld-2.19.90.so)
==564==    by 0x4018994: _dl_sysdep_start (in /usr/lib64/ld-2.19.90.so)
==564==    by 0x4004F17: _dl_start (in /usr/lib64/ld-2.19.90.so)
==564==    by 0x4000D47: ??? (in /usr/lib64/ld-2.19.90.so)
==564== 
==564== HEAP SUMMARY:
==564==     in use at exit: 0 bytes in 0 blocks
==564==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==564== 
==564== All heap blocks were freed -- no leaks are possible
==564== 
==564== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==564== 
==564== 1 errors in context 1 of 1:
==564== Jump to the invalid address stated on the next line
==564==    at 0x5A6: ???
==564==    by 0xFFF00023F: ???
==564==    by 0x4003BB1: dl_main (in /usr/lib64/ld-2.19.90.so)
==564==    by 0x4018994: _dl_sysdep_start (in /usr/lib64/ld-2.19.90.so)
==564==    by 0x4004F17: _dl_start (in /usr/lib64/ld-2.19.90.so)
==564==    by 0x4000D47: ??? (in /usr/lib64/ld-2.19.90.so)
==564==  Address 0x5a6 is not stack'd, malloc'd or (recently) free'd
==564== 
==564== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Speicherzugriffsfehler (Speicherabzug geschrieben)
Comment 5 Mark Wielaard 2014-05-09 11:09:04 UTC 
That rawhide valgrind bug is https://bugzilla.redhat.com/show_bug.cgi?id=1087933 "Valgrind does not recognize bndmov instruction". It was fixed yesterday, so the package might not yet have been updated in the rawhide repo. But please try again, you want valgrind-3.9.0-12.svn201403.
Comment 6 Martin Gieseking 2014-05-12 12:08:16 UTC 
I re-assigned the bug to zorba as I couldn't find evidence that GCC is actually the origin of the issues yet. 
I was able to fix parts of the code that provoke a segfault for simple queries like "1" but there seem to be are many more similar issues (double deallocation of objects) in the utility classes which let the binary crash in other contexts. I contacted the upstream developers and hope they can help fixing the bugs in a timely manner. I'm just wondering why these basic problems didn't pop up earlier with other compilers.
Comment 7 Martin Gieseking 2014-06-22 16:02:04 UTC 
*** Bug 1106712 has been marked as a duplicate of this bug. ***
Comment 8 Martin Gieseking 2014-06-22 16:19:37 UTC 
Finally, the upstream developers found the causes of the memory issues and fixed them. I created a corresponding snapshot build taken from the project's Git repo and pushed it to rawhide.
Thanks for all the hints and help I received in the last couple of weeks to resolve the build issue.
Note You need to log in before you can comment on or make changes to this bug.