This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Problem with threaded program
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: David Relson <relson at osagesoftware dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Sun, 02 Dec 2001 13:40:25 -0500
- Subject: Re: Problem with threaded program
- References: <4.3.2.7.2.20011202114313.00c40ab0@mail.osagesoftware.com>
> 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.
enjoy,
Andrew