Info Catalog gdb: Thread-Specific Breakpoints gdb: Thread Stops gdb: Observer Mode

gdb: Interrupted System Calls

 
 5.5.5 Interrupted System Calls
 ------------------------------
 
 There is an unfortunate side effect when using GDB to debug
 multi-threaded programs.  If one thread stops for a breakpoint, or for
 some other reason, and another thread is blocked in a system call, then
 the system call may return prematurely.  This is a consequence of the
 interaction between multiple threads and the signals that GDB uses to
 implement breakpoints and other events that stop execution.
 
    To handle this problem, your program should check the return value of
 each system call and react appropriately.  This is good programming
 style anyways.
 
    For example, do not write code like this:
 
        sleep (10);
 
    The call to 'sleep' will return early if a different thread stops at
 a breakpoint or for some other reason.
 
    Instead, write this:
 
        int unslept = 10;
        while (unslept > 0)
          unslept = sleep (unslept);
 
    A system call is allowed to return early, so the system is still
 conforming to its specification.  But GDB does cause your multi-threaded
 program to behave differently than it would without GDB.
 
    Also, GDB uses internal breakpoints in the thread library to monitor
 certain events such as thread creation and thread destruction.  When
 such an event happens, a system call in another thread may return
 prematurely, even though your program does not appear to stop.
 

Info Catalog gdb: Thread-Specific Breakpoints gdb: Thread Stops gdb: Observer Mode