Bug#411769: marked as done (Indefinitely looping atan2() function for amd64)
Your message dated Wed, 21 Feb 2007 00:07:04 +0100
with message-id <45DB7F18.9010300@aurel32.net>
and subject line Bug#411769: Indefinitely looping atan2() function for amd64
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: libc6
Version: 2.3.2.ds1-22sarge5
Architecture: amd64
CPU: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz
$ uname -a
Linux gloeiworm 2.6.18-2-amd64 #1 SMP Wed Nov 15 03:18:20 UTC 2006
x86_64 GNU/Linux
Problem:
======
With the "right" arguments the atan2() function will run on indefinitely
(forever unless killed). This is found for both C++ and C programs.
The simplest C program I could find that exhibits the problem is
file oef.c:
----
#include <math.h>
int main()
{
atan2(0.87600557019648551, 0.012279899574599516);
return 0;
}
----
build it:
gcc -o oef oef.c -lm
run it:
./oef &
This will run forever.
If I attach with gdb, I can see the following:
$ gdb
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-linux".
(gdb) attach 4492
Attaching to process 4492
Using host libthread_db library "/lib/libthread_db.so.1".
Reading symbols from /home/eric/pruts/oef...done.
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x00002b0a15e124ec in __signbitl () from /lib/libm.so.6
(gdb) where
#0 0x00002b0a15e124ec in __signbitl () from /lib/libm.so.6
#1 0x00002b0a15e13e46 in __signbitl () from /lib/libm.so.6
#2 0x00002b0a15e13681 in __signbitl () from /lib/libm.so.6
#3 0x00002b0a15e13522 in __signbitl () from /lib/libm.so.6
#4 0x00002b0a15ddd4e0 in fegetexcept () from /lib/libm.so.6
#5 0x00002b0a15df5b95 in atan2 () from /lib/libm.so.6
#6 0x0000000000400559 in main ()
The top of the stack is exactly the same as in my actual C++ program,
the behaviour depends on the exact values of the arguments of the atan2
function. In my actual program there are millions of calls to atan2()
that run just fine before this happens. The behaviour does not seem to
depend on optimization flags, also happens with mfpmath=387, and is the
same for C and C++. I got almost the same problem when I made my own
atan2() implementation, but then the __signbitl() in the stack was
called from an atan() function. The problem does not occur on my other
sarge system, which is 32bit Pentium 4.
It seems like this is a known problem with the 64 bit port of the math
library:
see http://sourceware.org/ml/libc-alpha/2003-11/msg00187.html
Please ask if you need more info,
Eric Meijer
--- End Message ---
--- Begin Message ---
Version: 2.3.6.ds1-12
Eric Meijer a écrit :
> Package: libc6
> Version: 2.3.2.ds1-22sarge5
>
> Architecture: amd64
> CPU: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz
> $ uname -a
> Linux gloeiworm 2.6.18-2-amd64 #1 SMP Wed Nov 15 03:18:20 UTC 2006
> x86_64 GNU/Linux
>
> Problem:
> ======
> With the "right" arguments the atan2() function will run on indefinitely
> (forever unless killed). This is found for both C++ and C programs.
> The simplest C program I could find that exhibits the problem is
>
> file oef.c:
> ----
> #include <math.h>
>
> int main()
> {
> atan2(0.87600557019648551, 0.012279899574599516);
>
> return 0;
> }
> ----
>
> build it:
> gcc -o oef oef.c -lm
>
> run it:
> ./oef &
> This will run forever.
>
> If I attach with gdb, I can see the following:
> $ gdb
> GNU gdb 6.3-debian
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "x86_64-linux".
> (gdb) attach 4492
> Attaching to process 4492
> Using host libthread_db library "/lib/libthread_db.so.1".
> Reading symbols from /home/eric/pruts/oef...done.
> Reading symbols from /lib/libm.so.6...done.
> Loaded symbols for /lib/libm.so.6
> Reading symbols from /lib/libc.so.6...done.
> Loaded symbols for /lib/libc.so.6
> Reading symbols from /lib/ld-linux-x86-64.so.2...done.
> Loaded symbols for /lib64/ld-linux-x86-64.so.2
> 0x00002b0a15e124ec in __signbitl () from /lib/libm.so.6
> (gdb) where
> #0 0x00002b0a15e124ec in __signbitl () from /lib/libm.so.6
> #1 0x00002b0a15e13e46 in __signbitl () from /lib/libm.so.6
> #2 0x00002b0a15e13681 in __signbitl () from /lib/libm.so.6
> #3 0x00002b0a15e13522 in __signbitl () from /lib/libm.so.6
> #4 0x00002b0a15ddd4e0 in fegetexcept () from /lib/libm.so.6
> #5 0x00002b0a15df5b95 in atan2 () from /lib/libm.so.6
> #6 0x0000000000400559 in main ()
>
> The top of the stack is exactly the same as in my actual C++ program,
> the behaviour depends on the exact values of the arguments of the atan2
> function. In my actual program there are millions of calls to atan2()
> that run just fine before this happens. The behaviour does not seem to
> depend on optimization flags, also happens with mfpmath=387, and is the
> same for C and C++. I got almost the same problem when I made my own
> atan2() implementation, but then the __signbitl() in the stack was
> called from an atan() function. The problem does not occur on my other
> sarge system, which is 32bit Pentium 4.
>
> It seems like this is a known problem with the 64 bit port of the math
> library:
> see http://sourceware.org/ml/libc-alpha/2003-11/msg00187.html
>
I confirm the problem on my Sarge system. However the problem is fixed
in the Etch glibc.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
--- End Message ---
Reply to: