Hangup in atan2() / __signbitl()
Hello,
I am running debian sarge, x86_amd64, on a brand new Core 2 system,
kernel 2.6.18-2-amd64 from http://kmuto.jp/debian/d-i/. I have this
machine to run my C++ fractal program, that I have been making
multi-threaded. Recently I got some hangups that I initially attributed
to my multi-threading programming capacities.
However, it appears that a very simple C-program with a call to the
atan2() function can do the trick using the "right" arguments:
file oef.c:
----
#include <math.h>
int main()
{
atan2(0.87600557019648551, 0.012279899574599516);
return 0;
}
----
build:
gcc -o oef oef.c -lm
run:
./oef &
runs indefinitely with a full cpu.
Attaching to it with gdb gives the following session:
$ 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,
and the behaviour depends on the arguments. 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.
Two questions:
Has anyone stumbled on this before, and do you have a fix?
I am not sure on what package to submit a bug. It seems the problem
would be in libm, so that would be the libc6 package? What kind of info
should I add?
Kind regards,
Eric Meijer
--
Eric L. Meijer
email: e.l.meijer@xs4all.nl
fractals: http://www.xs4all.nl/~elmeijer/
Reply to: