Mail Archives: djgpp/2013/06/18/21:45:14
"K.J.Williams" <lordwilliams1972 AT gmail DOT com> 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
- Raw text -