Very Computer

Hi,

I am new to unix programming and I am currently working on RedHat Linux
5.1.

But anyway I'm writing a program to send out the invoices for a company
and I access a database with the program.  Anyway when I loop back
through the program I get a segmentation fault.

I ran gdb and this is what it gave me...
Program received signal SIGSEGV, Segmentation fault.
chunk_free (ar_ptr=0x400ff8a0, p=0x8053990) at malloc.c:2892
malloc.c:2892: No such file or directory.

BTW this is a C++ program...
I'm thinking this is probably not enough info for anyone to adequately
figure out what is wrong so just tell me what to send.

thanks,
nate

--
Nathan Feger

University of Pittsburgh

1. Writing outside an allocated area.
2. Free-ing the same pointer more than once.
3. Free-ing with a pointer value not supplied by malloc.

All of these are easy to say, but since the offense and the crash can
be widely separated in time, it can be fiendishly difficult to find
the problem without the aid of software designed to monitor your program
for illegal use of dynamic storage.

--
                Fletcher Glenn

: I am new to unix programming and I am currently working on RedHat Linux
: 5.1.

i just installed that on my laptop, and i've been told that RH51 is a
disaster. if you can stand to do it, try downgrading to 4.2 or something.

: But anyway I'm writing a program to send out the invoices for a company
: and I access a database with the program.  Anyway when I loop back
: through the program I get a segmentation fault.

: I ran gdb and this is what it gave me...
: Program received signal SIGSEGV, Segmentation fault.
: chunk_free (ar_ptr=0x400ff8a0, p=0x8053990) at malloc.c:2892
: malloc.c:2892: No such file or directory.

okay, when you run gdb, you need to type 'where' at the prompt. this will
tell you where (duh) your program bombed. compile everything with the '-g'
flag (stick it in your makefile, or just on the command line when you type
'cc' or 'gcc').

: BTW this is a C++ program...

C++? maybe you don't want to be using malloc(). C++ people usually like to
use new(). i have no clue if they're compatable.

: I'm thinking this is probably not enough info for anyone to adequately
: figure out what is wrong so just tell me what to send.

if you can't get anything to work, then you should use your program to
tell you what's going on:

stick fprintf(stderr, "program got this far...\n") lines all over the
place.  consider using a log file for these things, too, if they become
too numerable.

every time you compare a pointer to something or try to dereference it,
test for == NULL. usually a segmentation fault comes from trying to
dereference a NULL pointer or other uninitialized pointer.

good luck,
-chris

  It explicitely explains which compiler will be used based on the program
  name you call.

  The primary problem comes from the fact that people used "gcc" as the
  C++ compiler, which they should never have done, you should always
  use g++.  In RH5.1 you should use gcc, egcs and g++ depending on what
  you want.

  RH5.1 Is a very nice release, they wanted to include egcs but did not
  want to break old non-ANSI C code, so they included the old GCC for
  C. Generally changing CC=egcs and CXX=g++ will resolve the problems
  with most Makefiles.

  This is how the compiler is setup:
  /usr/bin/cc   =gcc 2.7.2.3 (good C support)
  /usr/bin/gcc  = same as above
  /usr/bin/egcs = EGCS 1.0.2 if doing C & C++ should be used for CC
  /usr/bin/g++  = EGCS 1.0.2 should be used for C++

Quote:

>: But anyway I'm writing a program to send out the invoices for a company
>: and I access a database with the program.  Anyway when I loop back
>: through the program I get a segmentation fault.

>: I ran gdb and this is what it gave me...
>: Program received signal SIGSEGV, Segmentation fault.
>: chunk_free (ar_ptr=0x400ff8a0, p=0x8053990) at malloc.c:2892
>: malloc.c:2892: No such file or directory.

>okay, when you run gdb, you need to type 'where' at the prompt. this will
>tell you where (duh) your program bombed. compile everything with the '-g'
>flag (stick it in your makefile, or just on the command line when you type
>'cc' or 'gcc').

Quote:

>: BTW this is a C++ program...

>C++? maybe you don't want to be using malloc(). C++ people usually like to
>use new(). i have no clue if they're compatable.

Quote:

>: I'm thinking this is probably not enough info for anyone to adequately
>: figure out what is wrong so just tell me what to send.

>if you can't get anything to work, then you should use your program to
>tell you what's going on:

>stick fprintf(stderr, "program got this far...\n") lines all over the
>place.  consider using a log file for these things, too, if they become
>too numerable.

>every time you compare a pointer to something or try to dereference it,
>test for == NULL. usually a segmentation fault comes from trying to
>dereference a NULL pointer or other uninitialized pointer.

>good luck,
>-chris

Quote:>every time you compare a pointer to something or try to dereference it,
>test for == NULL. usually a segmentation fault comes from trying to
>dereference a NULL pointer or other uninitialized pointer.

    char *Pointer ;
    ...
    if( NULL == Pointer )
    {
        ...

It is amazing how many people accidentally use '=' instead of '=='.

This way, the compiler will barf, complaining about lvalues and your code
will be less buggy after a successful compilation.

Regards,

Andrew.

Quote:>Any crash in one of malloc's functions is always due to a mangled heap.

Quote:>it can be fiendishly difficult to find
>the problem without the aid of software designed to monitor your program
>for illegal use of dynamic storage.

Ying