CMakeLists.txt is outdated with respect to tests

[mulle-kybernetik-tv]

I didn't make a pull request for [https://github.com/mulle-kybernetik-tv/libdill/commit/b0fc47b0bc7e455df106e4e08eb8f83f9e9ec6a7](), because two of the tests also fail, when run from cmake. They work fine with autoconf and make test though

Here are the changes to CMakeLists.txt:

     file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/tests)
     set(test_files
+        tests/bundle.c
         tests/chan.c
         tests/choose.c
         tests/example.c
         tests/fd.c
-        tests/go.c
+        tests/go1.c
+        tests/go2.c
+        tests/go3.c
+        tests/go4.c
+        tests/go5.c
         tests/handle.c
+        tests/happyeyeballs.c
+        tests/http.c
         tests/iol.c
         tests/ipaddr.c
         tests/ipc.c
@@ -133,10 +140,15 @@ if(BUILD_TESTING)
         tests/rbtree.c
         tests/signals.c
         tests/sleep.c
+        tests/socks5.c
         tests/suffix.c
         tests/tcp.c
         tests/threads.c
-        tests/threads2.c)
+        tests/threads2.c
+        # tests/tls.c  # does not link on ubuntu due to undefined reference to symbol 'ERR_get_error@@OPENSSL_1_1_0'
+        tests/udp.c
+        tests/ws.c
+        )

Here are the test failures:

24/28 Test #24: test_tcp .........................***Exception: SegFault  0.31 sec
      Start 25: test_threads
25/28 Test #25: test_threads .....................***Exception: Other  0.33 sec
      Start 26: test_threads2

93% tests passed, 2 tests failed out of 28

Total Test time (real) =   6.84 sec

The following tests FAILED:
     24 - test_tcp (SEGFAULT)
     25 - test_threads (OTHER_FAULT)
FAILED: CMakeFiles/test.util 

For the tls test I got:

[69/86] Linking C executable tests/tls
FAILED: tests/tls 
: && /usr/bin/cc  -O3 -DNDEBUG   CMakeFiles/test_tls.dir/tests/tls.c.o  -o tests/tls  -rdynamic libdill.a -lpthread -lssl -lrt && :
/usr/bin/x86_64-linux-gnu-ld.bfd.real: libdill.a(tls.c.o): undefined reference to symbol 'ERR_get_error@@OPENSSL_1_1_0'
/usr/bin/x86_64-linux-gnu-ld.bfd.real: //usr/lib/x86_64-linux-gnu/libcrypto.so.1.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

This being on ubuntu 18.10. I have no idea why -lssl doesn't resolve the symbol, but didn't investigate further.

[sustrik]

As for the ERR_get_error, it's in libcrypto.so. You'll have to link with that as well.

[sustrik]

Ok, fixed. CMake build system now works for me. Please, try again.

[mulle-kybernetik-tv]

It builds fine now. The tcp test still fails though and now additionally the (new) tls test fails.

The following tests FAILED:
     24 - test_tcp (SEGFAULT)
     27 - test_tls (OTHER_FAULT)

[sustrik]

It works on my machine. What are the backtraces? What version of TLS are you using? Is there a difference between automake and cmake build command line?

[mulle-kybernetik-tv]

It builds like this

[82/86] /usr/bin/cc  -DDILL_THREADS -DHAVE_MPROTECT -DHAVE_POSIX_MEMALIGN -I../ -I../dns -O3 -DNDEBUG -MMD -MT CMakeFiles/test_tcp.dir/tests/tcp.c.o -MF CMakeFiles/test_tcp.dir/tests/tcp.c.o.d -o CMakeFiles/test_tcp.dir/tests/tcp.c.o   -c ../tests/tcp.c
 /usr/bin/cc  -O3 -DNDEBUG   CMakeFiles/test_tcp.dir/tests/tcp.c.o  -o tests/tcp  -rdynamic libdill.a -lpthread -lssl -lcrypto -lrt

The stacktrace doesn't show anything though:

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x0000000000000000 in ?? ()
(gdb) 

I am running this on a dual Xeon, if this makes a difference.

This is what autoconf does:

Makefile:1649: update target 'tests/tcp.o' due to: tests/tcp.c tests/.dirstamp tests/.deps/.dirstamp
echo "  CC      " tests/tcp.o;depbase=`echo tests/tcp.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
gcc -DPACKAGE_NAME=\"libdill\" -DPACKAGE_TARNAME=\"libdill\" -DPACKAGE_VERSION=\"5684026\" -DPACKAGE_STRING=\"libdill\ 5684026\" -DPACKAGE_BUGREPORT=\"sustrik@250bpm.com\" -DPACKAGE_URL=\"http://libdill.org/\" -DPACKAGE=\"libdill\" -DVERSION=\"5684026\" -DDILL_THREADS=1 -DDILL_PTHREAD=1 -DHAVE_POSIX_MEMALIGN=1 -DHAVE_MPROTECT=1 -DHAVE_LIBRT=1 -DHAVE_CLOCK_GETTIME=1 -DHAVE_EPOLL_CREATE=1 -DHAVE_EPOLL=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_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_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DDILL_SHARED=1 -I.     -g -O2 -MT tests/tcp.o -MD -MP -MF $depbase.Tpo -c -o tests/tcp.o tests/tcp.c &&\
mv -f $depbase.Tpo $depbase.Po
  CC       tests/tcp.o
Makefile:1370: update target 'tests/tcp' due to: tests/tcp.o libdill.la tests/.dirstamp
rm -f tests/tcp
echo "  CCLD    " tests/tcp;/bin/bash ./libtool --silent --tag=CC   --mode=link gcc  -g -O2   -o tests/tcp tests/tcp.o libdill.la -lrt 
  CCLD     tests/tcp
****

[sustrik]

Looks like stack corruption. You can step through the test to find out where exactly it happens. However, you mentioned that the test compiled by autoconf works. It may be worth checking what's different when compiling using cmake and autoconf.

[mulle-kybernetik-tv]

I posted the relevant autoconf, cmake lines already I think. What is missing ?

The problem is somewhere in int cr = go(client(5555));, but I don't know what the problem is because I am too slow to step past the time_assert :)

main () at ../../tests/tcp.c:271
271     errno_assert(rc == -1 && errno == ETIMEDOUT);
(gdb) 
272     int64_t diff = now() - deadline;
(gdb) 
273     time_assert(diff, 0);
(gdb) 
Expected duration 0, actual duration 73947 (../../tests/tcp.c:273)

[sustrik]

These are compile flags that may be relevant:

AUTOCONF

-DDILL_THREADS=1 -DDILL_PTHREAD=1 -DHAVE_POSIX_MEMALIGN=1 -DHAVE_MPROTECT=1 -DHAVE_CLOCK_GETTIME=1 -DHAVE_EPOLL_CREATE=1 -DHAVE_EPOLL=1 -O2

CMAKE

-DDILL_THREADS -DHAVE_MPROTECT -DHAVE_POSIX_MEMALIGN -O3

I would start with the optimization level. CMake uses 03, autoconf uses 02. May that cause the different behaviour?

[mulle-kybernetik-tv]

I won't be on linux for a few days, but will try to check it out next week.