public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: c++/4762
@ 2001-11-13 9:46 Paolo Carlini
0 siblings, 0 replies; only message in thread
From: Paolo Carlini @ 2001-11-13 9:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c++/4762; it has been noted by GNATS.
From: Paolo Carlini <pcarlini@unitus.it>
To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, pmu@sun3.oulu.fi,
nobody@gcc.gnu.org
Cc:
Subject: Re: c++/4762
Date: Mon, 19 Nov 2001 12:12:33 +0100
Hi,
it looks like the bug cannot be reproduced. I received these
exaplanations from Petri.
Cheers,
Paolo.
/////////////////////
Hello,
Thank you for your email.
The current history of the bug is following; while coding a numerical
program doing lengthy calculations (more than 50 hours), I came around
some weird behaviour.
The program has a linked list driving a numerical module with different
parameters. For some unknown reason, every 18th or 42th (depending on
the
platform) came out as NaN (it took about 5 hours to reach that
point). After three weeks of intense debugging I was able to track down
the bug into two subroutines (the program has more than 10000 lines of
code in it). That's when the weirdness started.
When examining the calculations producing NaN in debugger, none of the
variables where it came from by adding, subtracting, multiplying or
dividing were NaN. Some times sin() gave NaN. Few times even a variable
defined as constant was mysteriously changed to a NaN.
I checked the code for memory leaks, and found none. The size of the
program was not increasing during execution. I tried memory guardian
libraries (as Electric fence), which found nothing. I went through the
code many times and did'nt found any leaks or wild pointers; all the
reserved memory areas were released consistently. The NaN seemed just to
pop up as it pleased.
Then I started to search web for similiar bug reports, and found some.
Few
reports were written about NaN:s and unconsistent behaviour of the
floating point libraries. That's when I wrote the program in the bug
report and noticed it producing NaN:s. I ran it over one weekend, and it
gave out one NaN for about 1e9 calculations of sin() or cos(). That's
when
I wrote the report.
Afterwards, I gave the code in the report to some friends of mine, and
they were NOT able to reproduce the bug (with Redhat 7.2).
My mentioning about stack overflow was only a wild guess and propably a
wrong one.
However, I was able to get rid of the problem by nuking the RedHat
installation in my workstation and reinstalling newest version of it
(7.2). At solaris platform the problem was delt with by using a Sun
complier.
So the final reason of the bug is still open. But the original program
is
working just fine!
I noticed that the my report was hmmm... less than graciously done, but
that is result from local paranoia; I have the sendmail disabled in my
workstation, and I use other computer for emails and such. So, I'm sorry
for the mess.
I hope that these emails are going where they should go...
Best wishes,
Petri Mutka
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&pr=4762&database=gcc
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2001-11-19 11:26 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-11-13 9:46 c++/4762 Paolo Carlini
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).