This is the mail archive of the glibc-linux@ricardo.ecn.wfu.edu mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: problem with malloc?


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]