Hi all,

I have a C program which run inside a script like this:
-------------------------------------------------
#/bin/sh
export DIR1=...
export DIR2=...
export DIR3=...
:
:
myCprogram $DIR1/inputFile $DIR2/configFile anOption $DIR3/outputFile
# End Of Script
-------------------------------------------------

The script run smoothly.
Then, I try to run myCprogram in a korn shell command line,
without using the script.
Of course, I will not use those $DIR variable.
I will hard-code the fullpath filenames as arguments
of the C program.

Oh, my god, it returns segmentation fault.

On tracing the program, I find out that this piece of coding causes
the segmentation fault.
--------------------------------------------------
int readControl(buffer) 

char *buffer;                           /* buffer to contain record */ 

{ 

   char *p; 

   int c; 

 

   p = buffer;                           /* set pointer to buffer */ 

   while ((c = getc(gFileCntrPtr)) != EOF) /* get the next character */ 

   { 

     if (c == '\r')         /* test for line feeds in DOS files */
       continue;                         /* ignore line feeds */ 

 

     if (c == CONTROL_REC_TERM)          /* test for record terminator 
*/
     { 

           *p = '\0';                        /* null terminate buffer */ 

       return 0;                         /* return record ok */ 

     } 

     *p++ = c;                     /* add the character to buffer */
   } 

 

   return -1;                            /* return EOF */
}
--------------------------------------------------

Before calling this function,
buffer is char buffer[80].

Also, gFileCntrPtr is successfully opened,
which is actually the configFile.

CONTROL_REC_TERM is the char '\n'.

When, I display the character c,
it seems that the getc function loops forever to
cause the segmentation fault.

But, when running inside the script, it will NOT loop forever.

It seems that it cannot compare with the EOF.



Then, I remember that, about one month ago,
I experienced similar problem in another program.
When I compare something, say c, with EOF,
the variable c has to be declared as int instead of char.


Will there anybody give me some hints on this strange behaviour.
I am using AIX 5.1


Any suggestions and ideas are welcome.

Alvin SIU

Run myCprogram under the control of a debugger (gdb or dbx). You will 
then see what causes the segmentation fault.

Robert

Alvin SIU wrote:
> Hi all,
> 
> I have a C program which run inside a script like this:
> -------------------------------------------------
> #/bin/sh
> export DIR1=...
> export DIR2=...
> export DIR3=...
> :
> :
> myCprogram $DIR1/inputFile $DIR2/configFile anOption $DIR3/outputFile
> # End Of Script
> -------------------------------------------------
> 
> The script run smoothly.
> Then, I try to run myCprogram in a korn shell command line,
> without using the script.
> Of course, I will not use those $DIR variable.
> I will hard-code the fullpath filenames as arguments
> of the C program.
> 
> Oh, my god, it returns segmentation fault.
> 
> On tracing the program, I find out that this piece of coding causes
> the segmentation fault.
> --------------------------------------------------
> int readControl(buffer)
> char *buffer;                           /* buffer to contain record */
> {
>   char *p;
>   int c;
> 
> 
>   p = buffer;                           /* set pointer to buffer */
>   while ((c = getc(gFileCntrPtr)) != EOF) /* get the next character */
>   {
>     if (c == '\r')         /* test for line feeds in DOS files */
>       continue;                         /* ignore line feeds */
> 
> 
>     if (c == CONTROL_REC_TERM)          /* test for record terminator */
>     {
>           *p = '\0';                        /* null terminate buffer */
>       return 0;                         /* return record ok */
>     }
>     *p++ = c;                     /* add the character to buffer */
>   }
> 
> 
>   return -1;                            /* return EOF */
> }
> --------------------------------------------------
> 
> Before calling this function,
> buffer is char buffer[80].
> 
> Also, gFileCntrPtr is successfully opened,
> which is actually the configFile.
> 
> CONTROL_REC_TERM is the char '\n'.
> 
> When, I display the character c,
> it seems that the getc function loops forever to
> cause the segmentation fault.
> 
> But, when running inside the script, it will NOT loop forever.
> 
> It seems that it cannot compare with the EOF.
> 
> 
> 
> Then, I remember that, about one month ago,
> I experienced similar problem in another program.
> When I compare something, say c, with EOF,
> the variable c has to be declared as int instead of char.
> 
> 
> Will there anybody give me some hints on this strange behaviour.
> I am using AIX 5.1
> 
> 
> Any suggestions and ideas are welcome.
> 
> Alvin SIU
> 

Alvin SIU wrote:
> int readControl(buffer) 
> char *buffer;                           /* buffer to contain record */ 
> { 

You know that you're using an _ancient_ syntax for function headers, no?

/** make sure we have a buffer at all */
assert(buffer);
/** make sure we have a file open */
assert(gFileCntrPtr);

>    char *p; 
>    p = buffer;                           /* set pointer to buffer */ 

Totaly useless, you could have used 'buffer' in the first place.

>    while ((c = getc(gFileCntrPtr)) != EOF) /* get the next character */ 
>    { 
> 
>      if (c == '\r')         /* test for line feeds in DOS files */
>        continue;                         /* ignore line feeds */ 

/* alternatively: */
while(true)
{
  int c = getc(gFileCntrPtr);
  switch(c)
  { ... }
}

> Before calling this function,
> buffer is char buffer[80].

Which is plainly asking for trouble due to buffer overflows. Fix that first
and then see if it helps. If not, you might want to use a debugger or a
memory debugger like efence, debauch, valgrind..

> When I compare something, say c, with EOF,
> the variable c has to be declared as int instead of char.

Of course - in order to be able to hold any possible char value plus a
marker for EOF, you need something bigger than char...

-- 
http://www.erlenstar.demon.co.uk/unix/