CRN@BYUVM.BITNET (08/01/90)
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.
-- Cory
(crn@byuvm.bitnet)CRN@BYUVM.BITNET (08/02/90)
Subject: Re: This can't be a TurboC bug can it? >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; >> . . . >>} Tom Wiencko responds: >Turn off register optimization. There must be some code around the >function call which also uses the pointer - and with register optimizaton >turned on the compiler sometimes "forgets" which registers he has used >and which still have valid pointers in them. > >Took me two days of intense debugging to find this, and it was confirme >by Borland tech support. They also said that there is at this time no >fix for the problem. > >I am not sure if Turbo C++ has the same bug - I have not tested it yet >(but I have left the optimization off...). >Tom Thanks Tom, I owe you dinner. That was exactly the problem. Once I turned off register optimization ("-r-" on the command line that invokes tcc, if anyone is interested), the pointers were no longer getting destroyed and the code worked perfectly. Thanks also to everyone else who responded privately to me. And in response to the guy who (mildly) flamed me: I put *alot* of work into debugging that code segment before I placed the post. I had worked through the code many times and could not find any problem with my logic, that's why I speculated in the subject line of the post that I may have found a bug in Turbo C. I'll be more careful next time to make sure my post reflects the work I've done before I place it. By the way, I tested the code with Turbo C++ and the same thing happened, so it looks like it has the same bug. One quick question: Have you noticed a great speed difference between your code that was compiled using register optimization as opposed to your code compiled without such optimization? P.S. Tom, I'm serious about that dinner invitation. If you're ever in Provo (I know there's not a very high probability of that happening but I can't afford to fly you here -- I am just a poor grad student after all), look me up. I'm in the phone book. Thanks again, --Cory R. Newey (crn@byuvm.bitnet)
CRN@BYUVM.BITNET (08/02/90)
>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; >> . . . >>} Tom Wiencko responds: >Turn off register optimization. There must be some code around the >function call which also uses the pointer - and with register optimizaton >turned on the compiler sometimes "forgets" which registers he has used >and which still have valid pointers in them. > >Took me two days of intense debugging to find this, and it was confirme >by Borland tech support. They also said that there is at this time no >fix for the problem. > >I am not sure if Turbo C++ has the same bug - I have not tested it yet >(but I have left the optimization off...). >Tom Thanks Tom, I owe you dinner. That was exactly the problem. Once I turned off register optimization ("-r-" on the command line that invokes tcc, if anyone is interested), the pointers were no longer getting destroyed and the code worked perfectly. Thanks also to everyone else who responded privately to me. And in response to the guy who (mildly) flamed me: I put *alot* of work into debugging that code segment before I placed the post. I had worked through the code many times and could not find any problem with my logic, that's why I speculated in the subject line of the post that I may have found a bug in Turbo C. I'll be more careful next time to make sure my post reflects the work I've done before I place it. By the way, I tested the code with Turbo C++ and the same thing happened, so it looks like it has the same bug. One quick question: Have you noticed a great speed difference between your code that was compiled using register optimization as opposed to your code compiled without such optimization? P.S. Tom, I'm serious about that dinner invitation. If you're ever in Provo (I know there's not a very high probability of that happening but I can't afford to fly you here -- I am just a poor grad student after all), look me up. I'm in the phone book. Thanks again, --Cory R. Newey (crn@byuvm.bitnet)
poffen@sj.ate.slb.com (Russ Poffenberger) (08/02/90)
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
tom@stiatl.UUCP (Tom Wiencko) (08/03/90)
CRN@BYUVM.BITNET writes: > One quick question: Have you noticed a great speed difference >between your code that was compiled using register optimization as >opposed to your code compiled without such optimization? I never really noticed much difference, even though the code I was writing is pretty CPU intensive stuff, and I was running it on a 386SX - not really a speed demon. In general, I am singularly unimpressed with any of the optimization I have seen in anybody's micro compilers. Too bad, since they have had ample time to get it right. > P.S. Tom, I'm serious about that dinner invitation. If you're ever Never been to Provo, but if I get there, I'll at least call and say "hi." Tom -- Tom Wiencko (w) (404) 977-4515 gatech!stiatl!tom Wiencko & Associates, Inc.