Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!uunet!sjsca4!poffen
From: poffen@sj.ate.slb.com (Russ Poffenberger)
Newsgroups: comp.os.msdos.programmer
Subject: Re: This can't be a TurboC bug can it?
Message-ID: <1990Aug1.201440.23310@sj.ate.slb.com>
Date: 1 Aug 90 20:14:40 GMT
References: <1990Jul28.163656.12359@water.waterloo.edu> <11124@netcom.UUCP> <90212.153933CRN@BYUVM.BITNET>
Reply-To: poffen@sj.ate.slb.com (Russ Poffenberger)
Organization: Schlumberger Technologies, San Jose, CA.
Lines: 53

In article <90212.153933CRN@BYUVM.BITNET> CRN@BYUVM.BITNET writes:
>
>I am having a VERY weird problem in TurboC.  My code looks
>something like this:
>
>
>typedef struct{
>   . . .
>   char   *str;
>int    type;
>}FIELD;
>
>
>int proc(FIELD *fld)
>{
>   . . .
>   if(!valid_str(fld->str))
>      return ERROR;
>   . . .
>}
>
>Here's the weird part.  Using Turbo Debugger I have found that my
>program crashes right after this statement.  I perform a watch on
>fld, fld->str, fld->type.  Before the call to valid_str() all of the
>variables are fine.  Upon return from valid_str(), however, the
>pointer, fld, is screwed up which of course in turn screws up
>fld->str and fld->type.   I assume that fld is being overwritten
>somehow but I can't figure out how.  Valid_str() does nothing to
>manipulate fld and the only function that valid_str() calls is
>atoi() (yes, I do include stdlib.h).  If anyone has any pointers
>for me I'd sure appreciate hearing them.
>

It is very difficult with the little bit of code shown here.

People, if you want help on a problem, more detail of ALL relevant code would
help. In this case, the code for valid_str() and the part that calls proc()
would definitely help pinpoint the problem.

Quite often, in cases where pointers get munged, it is because something else
(possibly totally unrelated) is overwriting array or other memory bounds.
Another possibility is that memory that was "malloc'ed" was inadvertently
"free'd", causing a subsequent malloc to allocate the same memory.

The best way to debug is to set a watch variable on the affected pointer and
step through ALL functions, keeping an eye on the "watched" variable.



Russ Poffenberger               DOMAIN: poffen@sj.ate.slb.com
Schlumberger Technologies       UUCP:   {uunet,decwrl,amdahl}!sjsca4!poffen
1601 Technology Drive		CIS:	72401,276
San Jose, Ca. 95110             (408)437-5254