X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: "Rod Pemberton" Newsgroups: comp.os.msdos.djgpp Subject: Re: General Protection Fault error is intermittent Date: Tue, 18 Jun 2013 21:32:07 -0400 Organization: Aioe.org NNTP Server Lines: 76 Message-ID: References: <36e857f0-9899-496b-9fc6-32251e109888 AT googlegroups DOT com> <858cbded-7989-46e6-a997-93f842cdb3b0 AT googlegroups DOT com> NNTP-Posting-Host: CNsg4fVcCsvs3UaOgZtQCw.user.speranza.aioe.org X-Complaints-To: abuse AT aioe DOT org X-Notice: Filtered by postfilter v. 0.8.2 X-Newsreader: Microsoft Outlook Express 6.00.2800.2001 X-Priority: 3 X-MSMail-Priority: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.2001 Bytes: 4424 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com "K.J.Williams" wrote in message news:858cbded-7989-46e6-a997-93f842cdb3b0 AT googlegroups DOT com... > Well, thank you for looking over my code and pointing > out some problems that were confusing to me. ... > However, it doesn't explain why DJGPP will NOT produce > General Protection Fault warning [...] for my parstext.c program > - but it does it every time for my larger program WATT for the > same memory violation happening in parse_string(); that > is implemented there.. Did you run DJGPP's symify on the crash output? I assumed that symyify was how you knew strtok() with a NULL pointer was the issue. Symify will convert the call frame numbers to named function calls. > So I wrote the parstext.c to test string_parser() and it worked > after I compiled it with DJGPP - but when I implemented > string_parser in my bigger program which has many files that are > thousands of lines, I get a segmentation fault ( the general > protection fault warning by the compiler in this case ) for > allowing strtok() to return a NULL pointer as a error which is > copied to the string that gets passed to the calling statement > in my large program, that I was not checking for - because I > didn't know that I should have in the first place. But more > importantly a bad implementation use of strtok(). > > But it doesn't make sense to me that the general protection > fault warning doesn't happen with string_parser() in > parstext.c - which would have really helped me alot. > Thats why I am confused > .... Personally, I have a little bit of a problem identifying C coding errors in *other* people's code. Those on comp.lang.c are good for that, if they're good for anything. It was a hostile group the last time I was there... I tend to code in a subset of C which reduces certain C errors. Since we can't test WATT, we can only guess as to the error based on your descriptions. My guess is the actual crash problem is in WATT somewhere and not parsetext.c. I.e., it seems that the code in parsetext.c is not being misused in the exact same way. Of course, I haven't gone through your parsetext.c in detail. So, it could be parsetext.c has the same error, but it is just not triggering the same error. If you haven't run symify on WATT's crash output, do so. It should tell the crash point. Otherwise, you're probably going to have to debug WATT, either via GDB or another method such as printf()'s etc. You could attempt to turn up the warnings and error messages, e.g., gcc -Wall -ansi -pedantic. Your code didn't seem to be C89, so you might not want -ansi for now... You could also disable or not use optimizations, e.g., if you use gcc -O2 or gcc -O3, you could try -O0. Another option is to run the code through another compiler, e.g., OpenWatcom, with all warnings and errors enabled (-wx). Sometimes other compilers catch errors GCC doesn't, but usually these are trivial since GCC catches many errors, e.g., another compiler might catch a mismatch between signed and unsigned chars, etc. You should go through fix all errors *and* warnings so the WATT and parsetext.c code doesn't emit any. None. Sometimes those insignificant warnings are actually important. Go through them in order too. I.e., the first error or warning should be fixed first, second one second, ... Errors and warnings can cascade causing others, i.e., the first few are real but later ones aren't real. Rod Pemberton