View Problem Report: 259

Audit Trail:

From: Daniel Jacobowitz <drow@mvista.com>
To: lkiss@deltaprime.com
Cc: gdb-gnats@sources.redhat.com
Subject: Re: gdb/259: Thread receives Interrupted System Call error while waiting on message queue.
Date: Fri, 14 Dec 2001 20:38:20 -0500

 On Fri, Dec 14, 2001 at 05:48:29PM -0000, lkiss@deltaprime.com wrote:
 > If a thread is waiting on a message queue and another thread
 > is created (say in the main thread) the msgrcv() function
 > returns with an error code of EINTR.
 > 
 > This appears to be the case only while the program is under
 > gdb's control.
 
 That's right.  When a new thread is created, all threads running under
 GDB will receive a signal.  This is a fairly legitimate thing to do. 
 In an ideal world, the application would never find out; but in all
 current versions of Linux, they do.  This may be fixed in the kernel
 sometime soon.
 
 -- 
 Daniel Jacobowitz                           Carnegie Mellon University
 MontaVista Software                         Debian GNU/Linux Developer
Responsible-Changed-From-To: unassigned->chastain
Responsible-Changed-By: chastain
Responsible-Changed-When: Mon Sep 22 21:48:21 2003
Responsible-Changed-Why:
    
    Hello,
    
    I have a similar isse with 'sleep' returning early when pthread_create is invoked elsewhere in the process.
    
    As Daniel Jacobowitz says, it's legitimate for most system calls to return on receipt of a signal.  It's unfortunate that gdb+pthreads introduces more signals into the program, but it is legal for a system call to return early on receipt of a signal.  The moral is: always check the return value from a system call.
    
    I'm planning to document this in the gdb threads section of the manual, so that people will at least know what gdb is doing.
    
    Michael C
    GDB QA Guy
State-Changed-From-To: open->closed
State-Changed-By: chastain
State-Changed-When: Wed Nov 26 23:41:03 2003
State-Changed-Why:
    Hello,
    
    Thanks for your gdb bug report from 2001-12-14.
    
    Your analysis in the description is correct.  When a program is run under gdb, and the program creates or destroys a thread, and another thread in the program is inside a system call, the system call may return with -EINTR.
    
    That's because gdb puts hidden breakpoints on certain functions like thread creation so that it can track these events.  The same thing happens with user breakpoints, but it's more nasty to the gdb user when it happens with an internal implementation breakpoint.
    
    The next version of gdb will have a section in the manual documenting this limitation.  It's in the index under "thread breakpoints and system calls".
    
    You can wrap your system calls in loops that check for -EINTR and retry the system call.
    
    Michael C
    GDB QA Guy