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).