Bug 20540 - exempi-2.1.0 doesn't pass its test suite (NetBSD)
Summary: exempi-2.1.0 doesn't pass its test suite (NetBSD)
Status: RESOLVED FIXED
Alias: None
Product: exempi
Classification: Unclassified
Component: Problems (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) NetBSD
: medium normal
Assignee: Hubert Figuiere
QA Contact: Hubert Figuiere
URL:
Whiteboard:
Keywords: NEEDINFO
Depends on:
Blocks:
 
Reported: 2009-03-08 10:41 UTC by Thomas Klausner
Modified: 2017-09-04 09:40 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Thomas Klausner 2009-03-08 10:41:49 UTC
I'm trying exempi-2.1.0 on NetBSD-5.0RC2/amd64 with expat-2.0.1 and boost-1.38.0.

'cd exempti/test && make check' reports:
PASS: testcore.sh
terminate called after throwing an instance of 'boost::system_error'
[1]   Abort trap (core dumped) TEST_DIR=. BOOST...
FAIL: testinit
terminate called after throwing an instance of 'boost::system_error'
[1]   Abort trap (core dumped) TEST_DIR=. BOOST...
FAIL: testexempicore
terminate called after throwing an instance of 'boost::system_error'
[1]   Abort trap (core dumped) TEST_DIR=. BOOST...
FAIL: testserialise
terminate called after throwing an instance of 'boost::system_error'
[1]   Abort trap (core dumped) TEST_DIR=. BOOST...
FAIL: testwritenewprop
terminate called after throwing an instance of 'boost::system_error'
[1]   Abort trap (core dumped) TEST_DIR=. BOOST...
FAIL: testtiffleak
terminate called after throwing an instance of 'boost::system_error'
[1]   Abort trap (core dumped) TEST_DIR=. BOOST...
FAIL: testxmpfiles
terminate called after throwing an instance of 'boost::system_error'
[1]   Abort trap (core dumped) TEST_DIR=. BOOST...
FAIL: testxmpfileswrite
terminate called after throwing an instance of 'boost::system_error'
[1]   Abort trap (core dumped) TEST_DIR=. BOOST...
FAIL: test3
terminate called after throwing an instance of 'boost::system_error'
[1]   Abort trap (core dumped) TEST_DIR=. BOOST...
FAIL: testfdo18635
====================
9 of 10 tests failed
====================
*** Error code 1

There are two different error cases:
Most backtraces look like this:
 gdb test3 test3.core
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64--netbsd"...
Reading symbols from /usr/X11R7/lib/libexpat.so.1...done.
Loaded symbols for /usr/X11R7/lib/libexpat.so.1
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/libstdc++.so.6...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /usr/lib/libm.so.0...done.
Loaded symbols for /usr/lib/libm.so.0
Reading symbols from /usr/lib/libgcc_s.so.1...done.
Loaded symbols for /usr/lib/libgcc_s.so.1
Reading symbols from /usr/lib/libc.so.12...done.
Loaded symbols for /usr/lib/libc.so.12
Reading symbols from /usr/libexec/ld.elf_so...done.
Loaded symbols for /usr/libexec/ld.elf_so
Core was generated by `test3'.
Program terminated with signal 6, Aborted.
#0  0x00007f7ffd1db99a in _lwp_kill () from /usr/lib/libc.so.12
(gdb) bt
#0  0x00007f7ffd1db99a in _lwp_kill () from /usr/lib/libc.so.12
#1  0x00007f7ffd1db272 in abort () from /usr/lib/libc.so.12
#2  0x00007f7ffd8c0b0d in __gnu_cxx::__verbose_terminate_handler ()
   from /usr/lib/libstdc++.so.6
#3  0x00007f7ffd8c4f13 in __cxxabiv1::__terminate ()
   from /usr/lib/libstdc++.so.6
#4  0x00007f7ffd8c5a1b in __cxa_call_terminate () from /usr/lib/libstdc++.so.6
#5  0x00007f7ffd8c5807 in __gxx_personality_v0 () from /usr/lib/libstdc++.so.6
#6  0x00007f7ffd403a68 in _Unwind_Backtrace () from /usr/lib/libgcc_s.so.1
#7  0x00007f7ffd403cdb in _Unwind_Resume () from /usr/lib/libgcc_s.so.1
#8  0x000000000040952a in ~signal_handler (this=0x7f7fffffd400)
    at /usr/pkg/include/boost/test/impl/execution_monitor.ipp:686
#9  0x000000000040a6d9 in boost::execution_monitor::catch_signals (
    this=0x7f7fffffd6c0, F=@0x7f7fffffd6e0)
    at /usr/pkg/include/boost/test/impl/execution_monitor.ipp:764
#10 0x000000000040a71c in boost::execution_monitor::execute (
    this=0x7f7fffffd6c0, F=@0x7f7fffffd6e0)
    at /usr/pkg/include/boost/test/impl/execution_monitor.ipp:1091
#11 0x000000000040aca0 in main (argc=1, argv=<value optimized out>)
    at /usr/pkg/include/boost/test/minimal.hpp:115
(gdb)


The one exception:

gdb testxmpfiles
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64--netbsd"...
(gdb) r
Starting program: /home/wiz/exempi-2.1.0/exempi/tests/testxmpfiles
assertion "srcdir != __null" failed: file "utils.cpp", line 52, function "void p
repare_test(int, char**, const char*)"

Program received signal SIGABRT, Aborted.
0x00007f7ffd1db99a in _lwp_kill () from /usr/lib/libc.so.12
(gdb)
Comment 1 Hubert Figuiere 2009-03-08 19:18:02 UTC
bug 19858 has other symptoms but is about the same thing.

BTW, for the last bits, "assertion "srcdir != __null" failed: file "utils.cpp", line 52, function "void [...]" means that srcdir env is not defined.... This is expected and is set by "make check" therefor, it is not relevant.

Works fine here on boost 1.36 / Linux. 

If you really want to give a valid stack trace, just break for when the execption is thrown.
Comment 2 Thomas Klausner 2009-03-11 13:28:26 UTC
I started one of the tests as:
$ TEST_DIR=. BOOST_TEST_CATCH_SYSTEM_ERRORS=no gdb ./testxmpfiles

The last step before the segfault is
...
(gdb)
55
56      static TLS int g_error = 0;
57
58      static void set_error(int err)
59      {
60          g_error = err;
61      }
62
63      #else
64
(gdb) bt
#0  set_error (err=0) at exempi.cpp:60
#1  0x000000000040bd55 in xmp_files_open_new (
    path=0x7f7ffd00d088 "./../../samples/testfiles/BlueSquare.jpg",
    options=XMP_OPEN_READ) at exempi.cpp:255
#2  0x000000000040a29f in test_main (argc=<value optimized out>,
    argv=<value optimized out>) at test-xmpfiles.cpp:61
#3  0x0000000000409cb0 in boost::execution_monitor::catch_signals (
    this=0x7f7fffffd680, F=@0x7f7fffffd6a0)
    at /usr/pkg/include/boost/test/utils/callback.hpp:118
#4  0x0000000000409d5c in boost::execution_monitor::execute (
    this=0x7f7fffffd680, F=@0x7f7fffffd6a0)
    at /usr/pkg/include/boost/test/impl/execution_monitor.ipp:1091
#5  0x000000000040a6a0 in main (argc=1, argv=<value optimized out>)
    at /usr/pkg/include/boost/test/minimal.hpp:115
(gdb) s

Program received signal SIGSEGV, Segmentation fault.
set_error (err=0) at exempi.cpp:60
60          g_error = err;
(gdb)

Is this the information you're looking for?
What else can I provide?
Comment 3 Hubert Figuiere 2009-03-11 17:53:13 UTC
Looks like it is crashing when trying to access thread local data. No idea why. What is the compilation line like?
Comment 4 Thomas Klausner 2009-04-12 10:38:33 UTC
The compilation line is:
/bin/ksh ../../libtool --tag=CXX    --mode=compile g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE
_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"exempi\" -DVERSION=\"2.1.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_ST
AT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNIST
D_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DCHECKED_ENDIANNESS=1 -DICONV_CONST=const -DTLS=__thread -DHAVE_NATIVE_TLS=1 -DHAVE
_BOOST_TEST_UNIT_TEST_HPP=1 -I. -I../../public/include  -I../../public/include/client-glue  -I../../build/  -I./../common/  -I../.
./third-party/MD5  -Wall  -DUNIX_ENV=1 -DXMP_IMPL=1 -DXMP_ClientBuild=0  -D_FILE_OFFSET_BITS=64 -DHAVE_EXPAT_CONFIG_H=1 -DXML_STAT
IC=1 -I/usr/pkg/include -I/usr/X11R7/include -Wno-multichar -Wno-implicit -Wno-ctor-dtor-privacy  -funsigned-char -fexceptions -g
-O2 -MT ExpatAdapter.lo -MD -MP -MF .deps/ExpatAdapter.Tpo -c -o ExpatAdapter.lo ExpatAdapter.cpp

In the meantime I've found out that the NetBSD pthread library cannot coexist with anything using user defined stacks. Could this have anything to do with that core dump?
Comment 5 Thomas Klausner 2017-09-04 09:33:42 UTC
The tests in 2.3.0 do not report any errors. They do not seem to do anything else either though:

# make test
Making check in tests
make   testcore.sh  test1.xmp fdo18635.jpg fdo83313.jpg
`testcore.sh' is up to date.
`test1.xmp' is up to date.
`fdo18635.jpg' is up to date.
`fdo83313.jpg' is up to date.
make  check-TESTS
============================================================================
Testsuite summary for exempi 2.3.0
============================================================================
# TOTAL: 0
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================
Comment 6 Thomas Klausner 2017-09-04 09:40:32 UTC
If I install boost before, 12 tests are built and work.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.