Re: Problem with threaded program

[Daniel Jacobowitz <drow at mvista dot com>]

On Sun, Dec 02, 2001 at 01:40:25PM -0500, Andrew Cagney wrote:
> >Greetings,
> >
> >The problem below was originally reported to the Linux Kernel Mailing List. 
> >It looks to me to be a gdb problem.
> >
> >I used a freshly compiled and installed copy of gdb-5.1 (configured as 
> >"i686-pc-linux-gnu") for this test on a Pentium III 500mhz running the 
> >2.4.16 kernel.  The same problem happens with gdb-5.0.  gdb-4.18 appears to 
> >work fine.
> >
> >Here's the test program, test.c:
> >
> >#include <stdlib.h>
> >int main() {
> >  char *t="1.0";
> >  double d=0;
> >  d=strtod(t,(char **)NULL);
> >  printf( "%f\n", d );
> >  return 0;
> >}
> >
> >Build using "gcc -g -lpthread test.c"; run using "gdb a.out".
> >
> >If you step through the program one line at a time and display variable d 
> >after each assignment, the strtod() call seems to return 
> >"nan(0x8000000000000)", which is also shown by print().
> >
> >If you restart the program with a breakpoint at printf(), let it run, and 
> >display d at the breakpoint, the value shown is "1.000000" which is 
> >correct.
> >
> >Is this a defect in gdb, or is my analysis wrong?
> 
> Ah, looks like the GDB is corrupting a threaded programs FP registers 
> problem.
> 
> I'm 99% certain this is in the thread-db/kernel interface that GDB is 
> using.  Each time this crops up, the problem gets resolved with a 
> kernel/library update.
> 
> If someone can point out a definitive explination I'll add it to the 
> 5.1.1 PROBLEMS file.  That way it is at least clearly documented.
> 
> The apparent 4.18 -> 5.0 ``breakage'' would have occured because GDB 
> switched to using the thread-db/kernel interface.

Well, it happens every time we try to step over an fstpl instruction. 
We never call any of the SETREGS or POKE variants, only GETREGS and
GETFPXREGS; I don't see how it could really be our bug.

Note that in the non-threaded case we never call PTRACE_GETFPXREGS at
all.  That's:
 - an inefficency in the thread code, not surprisingly
 - highly suggestive of a kernel bug.

My money's on the kernel, but I don't have time to debug this just now.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer