home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!usc!cs.utexas.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!sgiblab!troi!steve
- From: steve@dbaccess.com (Steve Suttles)
- Newsgroups: comp.lang.c
- Subject: Re: Unsolveable bug
- Message-ID: <131@mccoy.dbaccess.com>
- Date: 8 Jan 93 04:14:20 GMT
- References: <204@zurich.spectrospin.ch>
- Organization: Cross Access Corp., Santa Clara, CA
- Lines: 27
- X-Newsreader: Tin 1.1 PL4
-
- A somewhat less drastic approach might be to install printfs every
- so often and see which ones run. Narrow down the failure to one line
- of code, and examine all values carefully.
-
- I've experienced your symptoms several times, and each time it boiled
- down to a variable that did not get initialized, and inherited
- whatever value that memory cell had in it. When I ran with the
- debugger, it inherited a different value, which altered the behavior.
- You may find that modifications to your program of any kind alter the
- behavior, but this is consistent (putting in printfs does change the
- runtime stack, after all...)
-
- Forget about bugs in malloc implementation. They would have been
- found. While your mistake might be in the area of malloc'ed memory,
- it is a mistake in the requests that were made, rather than the
- fulfillment of those requests. But if you honestly believe you
- haven't messed up with malloc, don't give up; keep looking until you
- find it. Computers only do what they are told, after all...
-
- When one is discovered that doesn't, it gets sent out to be fixed.
-
- sas
- --
- Steve Suttles Internet: steve@dbaccess.com Dr. DCL is IN!
- CROSS ACCESS Corporation UUCP: {uunet,sgiblab}!troi!steve Yo speako TECO!
- 2900 Gordon Ave, Suite 100 fax: (408) 735-0328 Talk data to me!
- Santa Clara, CA 95051-0718 vox: (408) 735-7545 HA! It's under 4 lines NOW!
-