0
votes

When linking to pthreads I get unexpected behavior during program execution, the ncurses interface becomes unresponsive, but the program does not crash. This is without using any pthread functionality, no threading headers or anything related to threads, just linking.

Are there any reasons that linking to a library can change program behavior without issuing warnings?

Pertinent information:

  • ncurses is also linked to the executable.
  • Everything is in a namespace.
  • Tried on current gcc and clang.
  • No compiler/linker errors or warnings using -Wall.
  • Arch Linux.

Linking ncurses and pthread together works fine on a smaller test program I made. So what I am looking for are more places to look, it's a library project and the codebase is a good size, it is all plain C++14 except for a small component that uses the ncurses library.

1
Most likely you just have some bug in your code and pthreads are not relevant. Or you have symbol name collision with pthreads. But it is not possible to guess since you didn't provide Minimal, Complete, and Verifiable example. You didn't even define what "unexpected behavior" is. - user7860670
no telepaths here... no one would be able to help if you don't provide code that illustrates behavior and what changes. Most likely your code contains UB - Swift - Friday Pie
The code base is large, I really have no idea where the bug is coming from, the unexpected behavior is the ncurses interface being unresponsive, not crashing. I have everything in a namespace and get no symbol name collision warning/errors. - A-n-t-h-o-n-y

1 Answers

1
votes

If you didn't changed anything in your code, didn't even include headers, but behavior changed, then your project contains UB. Possible UBs defined in standard, that may cause this:

  • Defining ANY function or global variables that match by name ones contained in standard headers
  • Defining something in std namespace.
  • Usage old C standard headers mixed with new C++ headers
  • Usage of variables that were initialized with undetermined value.
  • Array bound breaches, that do not lean to page fault or other kind of catastrophic result, may cause program change behavior.
  • Illegal use of side-effects of operators, e.g.: a ^=b ^= a ^=b;

and so on.

I recommend to check warnings, not only errors. There are certain warnings that are actually signs of semantic error or UB. AT least for GCC. Many novice programmers just ignore warnings as non-essential. E.g. this kind sneaks in quite often:

const char a = 167;

if(a == 167)  // compiler makes warning here, a ==-89 in this example
{
    // code will never be executed or even compiled
}

The code compiles but doesn't execute in expected way.