This is the mail archive of the
glibc-linux@ricardo.ecn.wfu.edu
mailing list for the glibc project.
Re: problem with malloc?
- To: glibc-linux at ricardo dot ecn dot wfu dot edu
- Subject: Re: problem with malloc?
- From: "Arthur H. Gold" <agold at bga dot com>
- Date: Fri, 21 Apr 2000 15:43:56 -0500
- CC: fheitka at attglobal dot net
- Organization: UTCS OOPS Group
- References: <200004211517.e3LFHpD19530@ricardo.ecn.wfu.edu>
- Reply-To: glibc-linux at ricardo dot ecn dot wfu dot edu
fheitka@attglobal.net wrote:
>
> I have written a C/C++ program that runs correctly using
Ain't no such thing as C/C++ -- it's one or the other!
> MS Visual C++ 5.0, IBM Visual Age C++ 4.0, and gnu gcc 2.95 on Sparc
> Solaris. When I compile and try to run the same program on Linux the
> program dumps core with a seg. fault. evidently generated in glibc
> malloc.c. Has anyone experienced a problem like this?
>
> The line in the code that precipitates the seg. fault. is simply
> allocating an pointer to make an array of pointers where the pointers
> point to identical structures. The structures are allocated using
> Template code. They are allocated using the "new" function. I am trying
> to come up with a simple
> test program, but here is the gist of what I do.
Alas, the difficulty you're having in generating a test case (that
fails, umm, appropriately) is quite understandable. See below.
>
> i.e.
>
> typedef struct ts {
> int ti;
> struct ts *next;
> } TS ;
>
> /* for each structure needed in in main program */
> new TS;
>
> /* each TS created is linked into a linked list
> then a list of pointers to each structure is created
> so that the list does not have to be iterated each
> time a particular structure is needed */
>
> TS_pointers = ( TS ** )malloc( number_of_TSes*sizeof( TS * ) );
>
> /* for each TS in list store a pointer to it in the array */
> TS_pointers[i] = temp_TS;
> temp_TS = a_TS->next;
>
> Fred
Receiving a SIGSEGV during a malloc usually indicates that you've
corrupted the heap in some way _before_ the call that generates the
fault.
Most likely you are either overrunning a buffer somewhere (messing with
the heap's internal metadata) or freeing something incorrectly (causing
a similar problem).
SIGSEGVs like this are often the most difficult to track down because of
the fact that by the time they occur, the code that actually _caused_
the problem is long since gone.
This might be a situation where Electric Fence or some other heap
information/debugging library would be of help.
HTH,
--ag
--
Artie Gold, Austin, TX (finger the cs.utexas.edu account for more info)
mailto:agold@bga.com or mailto:agold@cs.utexas.edu
--
A: Look for a lawyer who speaks Aramaic...about trademark infringement.