jog@ganzer.ecs.umass.edu (Ashwini ) (06/19/91)
Hello Everyone, I'm having a problem with malloc routine. I have a large program, so I may run out of memory (im using free wherever possible) but my program still crashes INSIDE malloc. Isnt this routine supposed to return a null pointer if it runs out of allocatable memory? The program crashes at the following statement which is inside malloc.(got by running through dbx). movb $ffffffff, (r10) I couldnt find anything in the faq list. ANY help would be greatly appreciated. Thanks Ashwini jog@ecs.umass.edu
dconway@hpldsla.sid.hp.com (Dan Conway) (06/20/91)
jog@ganzer.ecs.umass.edu (Ashwini ) writes: > Hello Everyone, > > I'm having a problem with malloc routine. I have a large program, > so I may run out of memory (im using free wherever possible) > but my program still crashes INSIDE malloc. Isnt this routine > supposed to return a null pointer if it runs out of allocatable > memory? The program crashes at the following statement which is > inside malloc.(got by running through dbx). > > movb $ffffffff, (r10) > > I couldnt find anything in the faq list. > ANY help would be greatly appreciated. > Thanks > Ashwini jog@ecs.umass.edu > ---------- > Two possibilities come to mind: you may have freed the same pointer twice without an intervening malloc, or you may have assigned through a pointer after freeing it. Either way, you might have messed up malloc's internal data structures enough to cause it to crash. Dan Conway dconway@hpsid.sid.hp.com
lsn@duke.cs.duke.edu (Lars S. Nyland) (06/21/91)
I have found over the years that failures that appear to be inside of malloc() usually have to do with corrupt data structures. How do they get corrupted? Not by malloc, not usually anyway. Usually, like many other bugs in C, some pointer has gone astray, and you have used it, assigned values to its location, and ruined malloc's data structures. I would bet that you still use a pointer after you have freed the memory it points to. You might amend your free statements to be more like: free(p); p = NULL; just to make sure that you don't use the pointers after you have freed them.
pckim@unisql.UUCP (Pyung-Chul Kim) (06/21/91)
In article <677448705@macbeth.cs.duke.edu> lsn@duke.cs.duke.edu (Lars S. Nyland) writes: > some stuffs deleted > >I would bet that you still use a pointer after you have freed >the memory it points to. You might amend your free statements >to be more like: > free(p); p = NULL; >just to make sure that you don't use the pointers after you have >freed them. Or, make sure the following should not happen: char str[n]; strcpy(str,another1); /* strlen(another1) >= n */ char *p; p = malloc(m); strcpy(p,another2); /* strlen(another2) >= m */ Hope this helps -- Pyung-Chul Kim UniSQL, Inc. 9390 Research Blvd., Kaleido II, Suite 220, Austin, TX 78759 Internet: execu!sequoia!unisql!pckim@cs.utexas.edu UUCP: {uunet, cs.utexas.edu!execu}!sequoia!unisql!pckim TEL: (512)343-7297 Ext. 332 FAX: (512)343-7383
bks@lima.berkeley.edu (Bradley K. Sherman) (06/22/91)
C programs that do a lot of mapping between 1 based entities (screen
positions, page layouts, etc.) and internal 0 based arrays often have
code that looks something like:
Yarra = malloc( MAXCOLS );
...
foo( row, col, otherstuff )
{
...
Yarra[col - 1] = something;
...
}
Now, exactly where to do the 1 to 0 mapping is not always clear and
sometimes, especially early in program development, it is done twice!
If "col" started out as 1 in this example and had already been converted
to 0 earlier in the program then the statement above will access Yarra[-1].
The result of accessing the minus-first element of a malloc'ed array
is implementation dependent, but if it doesn't core-dump immediately
you are in for one hell of a search for this bug when it does make
its presence known. Doing this using the MSC compiler on MessyDos
can produce some real consciousness raising effects.
---------------------------------
Brad Sherman (bks@alfa.berkeley.edu)
myjob( bug ){ fix(bug); done() ? fired() : myjob(getbug()); }s64421@zeus.usq.EDU.AU (house ron) (06/24/91)
pckim@unisql.UUCP (Pyung-Chul Kim) writes: >In article <677448705@macbeth.cs.duke.edu> lsn@duke.cs.duke.edu (Lars S. Nyland) writes: >> >some stuffs deleted >> Surely this should be "some stuff-ups deleted"? :-) -- Regards, Ron House. (s64421@zeus.usq.edu.au) (By post: Info Tech, U.C.S.Q. Toowoomba. Australia. 4350)
phil@phd.UUCP (H Phil Duby) (06/25/91)
In article <677448705@macbeth.cs.duke.edu> lsn@duke.cs.duke.edu (Lars S. Nyland) writes: > I have found over the years that failures that appear to > be inside of malloc() usually have to do with corrupt data > structures. How do they get corrupted? Not by malloc, not > usually anyway. > > Usually, like many other bugs in C, some pointer has gone > astray, and you have used it, assigned values to its location, > and ruined malloc's data structures. > > I would bet that you still use a pointer after you have freed > the memory it points to. You might amend your free statements > to be more like: > free(p); p = NULL; > just to make sure that you don't use the pointers after you have > freed them. Setting a pointer to NULL does not (at least on some systems) prevent it from being used. On my AMIGA, NULL <IS> zero, and is a valid memory location. There are <run time> tools that detect (and repair) accesses (especially modifications) to the low memory locations, but this does not prevent a program from <attempting> to use that memory. The offending program is not normally affected, and is usually not even known, except from the context of what programs are concurrently running. H. Phil Duby uunet!keyword!calgary!ajfcal!mtroyal!phd!phil (AMiga Users of Calgary) AMUCexpress BBS - 650 meg PD Software Fido net node 1:134/27 (403) 282-5137/5171/5224/5238 3/12/24/24 MNP bps
djimenez@ringer.cs.utsa.edu (Daniel Jimenez) (06/27/91)
In article <phil.7974@phd.UUCP> phil@phd.UUCP (H Phil Duby) writes: >In article <677448705@macbeth.cs.duke.edu> lsn@duke.cs.duke.edu (Lars S. Nyland) writes: >> I would bet that you still use a pointer after you have freed >> the memory it points to. You might amend your free statements >> to be more like: >> free(p); p = NULL; >> just to make sure that you don't use the pointers after you have >> freed them. >Setting a pointer to NULL does not (at least on some systems) prevent it >from being used. On my AMIGA, NULL <IS> zero, and is a valid memory >location. There are <run time> tools that detect (and repair) accesses >(especially modifications) to the low memory locations, but this does not >prevent a program from <attempting> to use that memory. The offending I would add that free (p); p = NULL; doesn't do the trick, even if NULL is a completely invalid address, like all bits one. There could still be *other* pointers hanging around that are aliased to what p used to point to. This kind of thing has caused me endless headaches. q = p; ... free (p); p = NULL; ... q->info = 'A'; /* Argh! It'll take me weeks to find this bug! */ -- * Daniel A. Jimenez * Please excuse my longwindedness. * djimenez@ringer.cs.utsa.edu * This Sun terminal makes everything * dajim@lonestar.utsa.edu * I write seem important. * Opinions expressed here are mine only, and not those of UTSA.