www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/08/21/13:44:53

From: kagel AT quasar DOT bloomberg DOT com
Date: Wed, 21 Aug 1996 12:40:29 -0400
Message-Id: <9608211640.AA03932@quasar.bloomberg.com >
To: ac387 AT YFN DOT YSU DOT EDU
Cc: djgpp AT delorie DOT com
In-Reply-To: <4ved7k$gps@news.ysu.edu> (ac387@YFN.YSU.EDU)
Subject: Re: memory overwriting itself??
Reply-To: kagel AT dg1 DOT bloomberg DOT com

   Errors-To: postmaster AT ns1
   Xref: news2.mv.net comp.os.msdos.djgpp:7714
   From: ac387 AT YFN DOT YSU DOT EDU (randall williams)
   Newsgroups: comp.os.msdos.djgpp
   Date: 21 Aug 1996 07:18:12 GMT
   Organization: St. Elizabeth Hospital, Youngstown, OH
   Lines: 24
   Reply-To: ac387 AT yfn DOT ysu DOT edu (randall williams)
   Nntp-Posting-Host: yfn.ysu.edu
   Dj-Gateway: from newsgroup comp.os.msdos.djgpp
   Content-Type: text
   Content-Length: 1072


   I finally finished, sort of, a project I've been working on.

   I found a problem maybe a bug. I have a function that uses the
   system() to make a dir list file and then it reads the file
   in for a directory menu. I know it can be done another way, but
   I do the same thing with a program's output and it saves some
   space. the function also moves around the directory tree, so it
   has to be able to read the directory several times. The open file
   is closed after it is read, and removed with unlink().

   After several steps through directories, the program crashes and I
   get usually SIGFPE, SIGBUS, or out of file handles. GDB showed me
   the divide by zero problem and I found an index counter was 0.
   The index counter is initialized to 1 and should never be zero
   since it only ever counts up. is there any easy way to find this
   bug? is this a bug in gcc? suggestions on narrowing this down?

   The bad thing is that another compiler doesn't have this bug with
   the same source code.

You could set a watch point on the index counter in GDB and it will break when
the value is changed.  Just breakpoint near where the value was last good and
set the watch then so you do not have to deal with breaks at all of the
legitimate increments on this variable.  Then continue and wait (watch pointing
is not fast).

-- 
Art S. Kagel, kagel AT quasar DOT bloomberg DOT com

A proverb is no proverb to you 'till life has illustrated it.  -- John Keats

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019