Article View: comp.os.msdos.programmer
Article #1760Re: This can't be a TurboC bug can it?
From: Russ Poffenberger
Date: Wed, 01 Aug 1990 20:14
Date: Wed, 01 Aug 1990 20:14
53 lines
2492 bytes
2492 bytes
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
Technical Details
Message-ID:
<1990Aug1.201440.23310@sj.ate.slb.com>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!uunet!sjsca4!poffenReferences:
<1990Jul28.163656.12359@water.waterloo.edu> <11124@netcom.UUCP> <90212.153933CRN@BYUVM.BITNET>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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