[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Hangup in atan2() / __signbitl()


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;

gcc -o oef oef.c -lm

./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: