Why adding a cpp file to be compiled with Cmake might lead to a segmentation fault in the middle of execution of a program?

Question

I compile and run program normally as follows:

set(A_SRC a.hpp a.cpp)

When I add second compilation target as following:

set(A_SRC a.hpp a.cpp b.hpp b.cpp)

It leads to a SegFault during execution Segmentation fault (core dumped), coredump is has no valuable information about the cause.

b.hpp is not used anywhere, all the code / functions inside b are inside a separate namespace. b.hpp share similarity with one of the linked libraries.

What could be a cause of the segfault? How can one cause a SegFault by simply compiling more code?

More info JIC:

Stacktrace:

#0  0x00007f489ba27550 in ?? ()
#1  <signal handler called>
#2  0x00007f489ba27550 in ?? ()
#3  <signal handler called>
#4  0x00007f495daf87b1 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /usr/lib/x86_64-linux-gnu/libpthread.so.0
#5  0x00007f465c8e9c66 in __gthread_cond_timedwait (__cond=0x55fdf3180b88,
    __mutex=0x55fdf3180b60, __abs_timeout=0x7ffe36106dd0)
    at /usr/include/x86_64-linux-gnu/c++/9/bits/gthr-default.h:872
#6  0x00007f465c8eb676 in std::condition_variable::__wait_until_impl<std::chrono::duration<long, std::ratio<1l, 1000000000l> > > (this=0x55fdf3180b88, __lock=..., __atime=...)
    at /usr/include/c++/9/condition_variable:188
#7  0x00007f465c8eab4a in std::condition_variable::wait_until<std::chrono::_V2::steady_clock, std::chrono::duration<long, std::ratio<1l, 1000000000l> > > (this=0x55fdf3180b88,
    __lock=..., __atime=...) at /usr/include/c++/9/condition_variable:121
#8  0x00007f465c8ea1c5 in std::condition_variable::wait_for<long, std::ratio<1l, 1000l> > (
    this=0x55fdf3180b88, __lock=..., __rtime=...)
...

And the other threads aren't helpful either:

(gdb) info threads
  Id   Target Id                       Frame
* 1    Thread 0x7f495d78c740 (LWP 18)  0x00007f489ba27550 in ?? ()
  2    Thread 0x7f4661aea700 (LWP 121) 0x00007f495d86f3bf in clock_nanosleep ()
   from /usr/lib/x86_64-linux-gnu/libc.so.6
  3    Thread 0x7f480bcac700 (LWP 138) 0x00007f495daf8376 in pthread_cond_wait@@GLIBC_2.3.2
    () from /usr/lib/x86_64-linux-gnu/libpthread.so.0
  4    Thread 0x7f48a1cc6700 (LWP 128) 0x00007f495d8a4aff in poll ()
   from /usr/lib/x86_64-linux-gnu/libc.so.6
  5    Thread 0x7f47bdc9f700 (LWP 145) 0x00007f495daf8376 in pthread_cond_wait@@GLIBC_2.3.2
    () from /usr/lib/x86_64-linux-gnu/libpthread.so.0
  6    Thread 0x7f4885cc1700 (LWP 130) 0x00007f495d8b2c90 in accept4 ()
   from /usr/lib/x86_64-linux-gnu/libc.so.6

Answer 1

What could be a cause of the segfault? How can one cause a SegFault by simply compiling more code?

This is strange but perhaps the extra source code you are adding is executing code somehow.

Perhaps something related to globals. I had issues on the past working on embedded systems where global variables allocated dynamic memory.

Does C++ call destructors for global and class static variables?

Or you are using predefined functions that implicitly execute logic. For example DLLMain. I know you are on unix but the point still stands.

Try compiling with higher warning levels. Your code might be violating C++ rules like ODR.

Or using a tool like Valgrind to help you debug the issue.