[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::decc

Title:	DECC
Notice:	General DEC C discussions
Moderator:	TLE::D_SMITHNTE

Created:	Fri Nov 13 1992
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	2212
Total number of notes:	11045

2121.0. "Memory allocation problem with drand48" by RICKS::HOOKER (Franklin Hooker, 225-4360, HLO2-3/D11) Wed Mar 12 1997 17:04

I have run across a problem in a customer's code which
calls drand48 many times.  Drand48 calls malloc but
never calls free.  Drand48 also calls __get_libc_context
which also calls malloc without ever calling free.  Another
problem is that the value returned from malloc is not tested.

This results two problems...
1.  The program runs out of space when it probably shouldn't.
2.  Somewhere within drand48 memory accesses result based on
    a pointer of zero when malloc fails.

Thanks
Franklin

p.s. erand48 appears to have the same problem.

T.R Title User Personal
Name Date Lines

2121.1 Looks like a bug QUARRY::neth Craig Neth Wed Mar 12 1997 17:24 24

T.R	Title	User	Personal Name	Date	Lines
2121.1	Looks like a bug	QUARRY::neth	Craig Neth	`Wed Mar 12 1997 17:24`	24
	First of all, I presume you are talking about DIGITAL UNIX, no? What version? __get_libc_context calls malloc (actually calloc()) _once_ to initialize the libc context, and that memory does eventually get freed, although it may happen after your malloc tool has decided it wasn't freed (it happens as libc is tearing things down, which is a tricky time. Tools like this usually need memory but if libc were shut down then they wouldn't be able to get any...) It looks like there is a destructor for the drand48 malloc'ed memory, but I can't quite see where it gets called from. I suspect it gets freed in the same place that the libc_context is getting freed. Still, it seems fishy that it seems to be calling malloc alot, and the 'not checking the return' is definitely a bug. Please file a QAR so that the libc maintainer will see this and be able to track/respond to it. Node GORGE, account QAR_INTERNAL. Thanks.

First of all, I presume you are talking about DIGITAL UNIX, no?   What
version?

__get_libc_context calls malloc (actually calloc()) _once_ to initialize 
the libc context, and that memory does eventually get freed, although it
may happen after your malloc tool has decided it wasn't freed (it happens
as libc is tearing things down, which is a tricky time.   Tools like
this usually need memory but if libc were shut down then they wouldn't be 
able to get any...)

It looks like there is a destructor for the drand48 malloc'ed memory, but
I can't quite see where it gets called from.   I suspect it gets freed
in the same place that the libc_context is getting freed.   Still, it seems
fishy that it seems to be calling malloc alot, and the 'not checking the 
return' is definitely a bug.

Please file a QAR so that the libc maintainer will see this and be able
to track/respond to it.  Node GORGE, account QAR_INTERNAL.   Thanks.