0

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.

A-n-t-h-o-n-y
  • 410
  • 6
  • 14
  • 3
    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](http://stackoverflow.com/help/mcve). You didn't even define what "unexpected behavior" is. – user7860670 May 06 '17 at 05:58
  • 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 May 06 '17 at 05:58
  • 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 May 06 '17 at 13:47

1 Answers1

1

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.

Swift - Friday Pie
  • 12,777
  • 2
  • 19
  • 42
  • *"Defining ANY function or global variables that match anything contained in standard headers"* - What do you mean by "match"? *"Usage old C standard headers mixed with new C++ headers"* - What does this have to do with UB? *"Minor array bound breaches, that do not lean to page fault"* - It doesn't need to be minor to be UB, and it doesn't need to cause a page fault. *"compiler makes warning here"* - No, not here but at the point of initialisation. – Christian Hackl May 06 '17 at 09:30
  • @Christian Hackl Match by name. Clarified that. they a) listed as actions that can cause UB of program B) I ran into issues (and there are some examples of that on SO ) I agree with array bound issue, that's just most common outcome. GCC warns at assignment only if it is in pedantic mode. Most of compilers do not warn at that assignment at all, it's not required as result of such assignment is defined. Compiler warns there because a) comparison may cause unexpected results b) in case of constant variable whole code branch would be cut out. Even in that case not all compilers do that,e.g MSVC – Swift - Friday Pie May 06 '17 at 11:30
  • @Swift When you say using old standard headers, does that include the c++ versions of old c headers, such as ? Thanks for the response, going to look around for sources of UB. – A-n-t-h-o-n-y May 06 '17 at 14:15
  • 1
    @Swift You were correct about the undefined behavior, it turns out there was a deadlock in the code, but without linking to pthread it seems that the mutex methods were optimized out in some way and no locking occurs. – A-n-t-h-o-n-y May 06 '17 at 23:12
  • @A-n-t-h-o-n-y what kind of mutex you was using? And, about headers, I meant only headers like stdlib.h. cstdlib and alike might define some flags that affect compilation of stdlib.h, may have completely different implementation or may be a mix of those two options, to make content compatible with C++ reality - after all C and C++ behave differently after all. – Swift - Friday Pie May 07 '17 at 08:49
  • @Swift std::mutex – A-n-t-h-o-n-y May 07 '17 at 17:27
  • @A-n-t-h-o-n-y it is possible that std::mutex used spinlocks or something else when not linked against pthreads. there is std::async also, but their implementation may rely on pthreads or may not.. it is an "interstinger" topic (in Chinese way) on embedded OSes or some unusual flavors, where kernel got some native thread support. Note that you're not inherently exception-safe if you use pthreads - it's a C library - (or even std::thread), std::async ensures some of that. – Swift - Friday Pie May 09 '17 at 12:32
  • 1
    @Swift I asked a question on that recently http://stackoverflow.com/a/43826431/5680070 – A-n-t-h-o-n-y May 09 '17 at 14:19
  • 1
    @A-n-t-h-o-n-y yeah, the answer was true in case of gcc or clang on Linux. with MSVC program may behave differently because there is working implementation of mutex::lock ( all windows apps inherently multi-threaded, due platform, there are thread-controlling functions in run-time AND API). Dunno what happens with Mac, on Solaris\Debin flavor I work with (SPARC) mutex is reentrant by default, so calling lock several times from same thread does nothing, so comment about UB is true too. – Swift - Friday Pie May 09 '17 at 15:45