X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Received: by 10.224.57.65 with SMTP id b1mr15079052qah.2.1371852305043;
        Fri, 21 Jun 2013 15:05:05 -0700 (PDT)
X-Received: by 10.50.66.134 with SMTP id f6mr10031igt.13.1371852305006; Fri,
 21 Jun 2013 15:05:05 -0700 (PDT)
Newsgroups: comp.os.msdos.djgpp
Date: Fri, 21 Jun 2013 15:05:04 -0700 (PDT)
In-Reply-To: <kpr1f4$m1h$1@speranza.aioe.org>
Complaints-To: groups-abuse AT google DOT com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=71.222.72.40; posting-account=jrLHRgkAAABPV01ZW_RN_U6Tm5UnYNUx
NNTP-Posting-Host: 71.222.72.40
References: <36e857f0-9899-496b-9fc6-32251e109888 AT googlegroups DOT com>
 <kpo3gh$4qo$1 AT speranza DOT aioe DOT org> <858cbded-7989-46e6-a997-93f842cdb3b0 AT googlegroups DOT com>
 <kpr1f4$m1h$1 AT speranza DOT aioe DOT org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <9c0f565c-fd72-4887-8bdf-9e4b520ce6f1@googlegroups.com>
Subject: Re: General Protection Fault error is intermittent
From: "K.J.Williams" <lordwilliams1972 AT gmail DOT com>
Injection-Date: Fri, 21 Jun 2013 22:05:05 +0000
Content-Type: text/plain; charset=ISO-8859-1
Bytes: 4238
Lines: 110
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On Tuesday, June 18, 2013 6:32:07 PM UTC-7, Rod Pemberton wrote:
> "K.J.Williams" <lordwilliams1972 AT gmail DOT com> wrote in message

> 
> 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.
> 

Thats how I discovered the error... I was not understanding what 
kind of error message I was getting , until - I had to do some 
hard thinking about the problem. 

> 
> 
> > 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.
> 

string_parser(); was copied directly into one of the source code scripts 
in my project that I use to compile that creates WATT. 


> 
> If you haven't run symify on WATT's crash output, do so.  It

This was done..


> 
>  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.
> 

That's how I usually fix my programming from errors - the first error 
in a list of errors, shows a domino effect with other pieces of code. 

> 
> 
> 
> Rod Pemberton

KJW