>Raises its ugly head again.  Any of you UNIX/Linux gurus have an idea
around
>a segmentation fault?

The program needs to be fixed.  You might be able to find a fixtest level
which may get you by the problem.  For reference, here's my list of what
can cause segfaults...

Segmentation Fault (Segmentation Violation (SEGV))
        The program attempts to write to a region of memory to which it does
not
        have access.  Is typically a pointer usage problem, as in the
following:
        - Writing past the end of an array (table): "subscript out of
range".
        - Attempting to store into a string literal, as in:
           string = "abcde";   *(string + 1) = 'B';
          Note that string literals are contained in the Application Program
          Text area of the address space, which is read-only.
        - Using an uninitialized pointer.
        - Using no indirection where indirection (&something) is required,
or
          single indirection where double indirection is required.  A common
          error is passing a struct_name instead of &struct_name.
        - The destination of sscanf being specified as the object itself
(such
          as an int) rather than the address of it.
        - In "printf(%s)" for an int value, which instead wants
"printf(%d)".
        - In "printf(%s)", no variable supplied for the value, or too few
          variables coded.
        - In computing a position within a table, using just the offset
value
          rather than table base address plus offset.
        - Your code attempts to modify a read-only string literal.
        This problem can sometimes be caused by defective libraries, as in
        needing to upgrade to the latest libc.
        In occasional instances, giving a program more memory *might* help.
        Note that dereferencing a zeroed pointer will not result in a
        Segmentation Fault in AIX: IBM carried on the mainframe tradition of
        having low virtual memory map to the nucleus (kernel).  See "Address
        Space".

  Richard Sims, BU