Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   malloc (http://www.velocityreviews.com/forums/t868421-malloc.html)

Joe keane 02-16-2012 09:04 PM

malloc
 
Bugs of memory allocation will make you mad.

Bugs *in* memory allocation will put you in the cuckoo people place.

BGB 02-16-2012 11:16 PM

Re: malloc
 
On 2/16/2012 2:21 PM, Devil with the China Blue Dress wrote:
> In article<jhjr14$rjk$1@reader1.panix.com>, jgk@panix.com (Joe keane) wrote:
>
>> Bugs of memory allocation will make you mad.
>>
>> Bugs *in* memory allocation will put you in the cuckoo people place.

>
> Which is why they are exceedingly rare. Nearly all allocation problems are due
> to the program storing outside array bounds.
>


which are annoyingly difficult to track down sometimes...


it would be nice if compilers would offer an option (as a debugging
feature) to optionally put in bounds checking for many operations (it is
also possible to do this without adding fat pointers or fundamentally
changing how the language works, although it would still introduce a
run-time cost).

simple idea:
on a array access, identify the memory object pointed-to by the base
pointer (heap-lookup);
determine if the address being assigned to is the same object (possibly,
another heap lookup, or checking the target against the first object);
if not, blow up.

now, if the person can't afford the cost, they don't have to use the
feature.


some other use cases are a little harder, say:
double *fp;
fp=...
while(fp) { *fp=*fp+1; fp++; }

the issue would be that, potentially, the pointer could jump from one
object to the next without the run-time checks noticing.

a secondary defense could be to place "trip wires" in the heap between
objects, and if a memory-write check determines that the pointer points
to such a trip-wire, then an exception can be raised (one option for
such trip-wires is to have them occupy the same physical space as
memory-object headers or similar, and maybe also several for words
following the end of a memory-object).


although, without the explicit testing or throwing (kind of a problem
with a standard compiler), I have used similar before as a means to
attempt to debug array overruns with several custom memory managers of
mine (the memory managers will make some attempt to detect and
diagnose/report these sorts of problems).


or such...


Eric Sosman 02-17-2012 01:27 AM

Re: malloc
 
On 2/16/2012 4:21 PM, Devil with the China Blue Dress wrote:
> In article<jhjr14$rjk$1@reader1.panix.com>, jgk@panix.com (Joe keane) wrote:
>
>> Bugs of memory allocation will make you mad.
>>
>> Bugs *in* memory allocation will put you in the cuckoo people place.

>
> Which is why they are exceedingly rare. Nearly all allocation problems are due
> to the program storing outside array bounds.


The only allocator bug I have personally encountered was with
a malloc() implementation that never, never returned NULL. When it
ought to have returned NULL, it crashed the program instead ...

--
Eric Sosman
esosman@ieee-dot-org.invalid

Goran 02-17-2012 07:40 AM

Re: malloc
 
On Feb 17, 2:27*am, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> On 2/16/2012 4:21 PM, Devil with the China Blue Dress wrote:
>
> > In article<jhjr14$rj...@reader1.panix.com>, j...@panix.com (Joe keane) wrote:

>
> >> Bugs of memory allocation will make you mad.

>
> >> Bugs *in* memory allocation will put you in the cuckoo people place.

>
> > Which is why they are exceedingly rare. Nearly all allocation problems are due
> > to the program storing outside array bounds.

>
> * * *The only allocator bug I have personally encountered was with
> a malloc() implementation that never, never returned NULL. *When it
> ought to have returned NULL, it crashed the program instead ...


If you don't provide a way to verify that, it didn't happen ;-), and
there was a bug in your code.

Goran.

Goran 02-17-2012 07:43 AM

Re: malloc
 
On Feb 16, 10:04*pm, j...@panix.com (Joe keane) wrote:
> Bugs of memory allocation will make you mad.
>
> Bugs *in* memory allocation will put you in the cuckoo people place.


.... Provided you really encountered one. If you don't provide
verifiable evidence that you did, you didn't.

Goran.

Keith Thompson 02-17-2012 10:26 AM

Re: malloc
 
Goran <goran.pusic@gmail.com> writes:
> On Feb 17, 2:27*am, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>> On 2/16/2012 4:21 PM, Devil with the China Blue Dress wrote:
>>
>> > In article<jhjr14$rj...@reader1.panix.com>, j...@panix.com (Joe keane) wrote:

>>
>> >> Bugs of memory allocation will make you mad.

>>
>> >> Bugs *in* memory allocation will put you in the cuckoo people place.

>>
>> > Which is why they are exceedingly rare. Nearly all allocation problems are due
>> > to the program storing outside array bounds.

>>
>> * * *The only allocator bug I have personally encountered was with
>> a malloc() implementation that never, never returned NULL. *When it
>> ought to have returned NULL, it crashed the program instead ...

>
> If you don't provide a way to verify that, it didn't happen ;-), and
> there was a bug in your code.


I suspect he's referring to the malloc() implementation
on typical Linux systems, which overcommits memory by default.
It can allocate a large chunk of address space for which no actual
memory is available. The memory isn't actually allocated until
the process attempts to access it. If there isn't enough memory
available for the allocation, the "OOM killer" kills some process
(not necessarily the one that did the allocation).

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Noob 02-17-2012 10:44 AM

Re: malloc
 
Eric Sosman wrote:

> The only allocator bug I have personally encountered was with
> a malloc() implementation that never, never returned NULL. When it
> ought to have returned NULL, it crashed the program instead ...


Visual Studio 6 used to crash on free(NULL).

Goran 02-17-2012 12:01 PM

Re: malloc
 
On Feb 17, 11:26*am, Keith Thompson <ks...@mib.org> wrote:
> Goran <goran.pu...@gmail.com> writes:
> > On Feb 17, 2:27*am, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> >> On 2/16/2012 4:21 PM, Devil with the China Blue Dress wrote:

>
> >> > In article<jhjr14$rj...@reader1.panix.com>, j...@panix.com (Joe keane) wrote:

>
> >> >> Bugs of memory allocation will make you mad.

>
> >> >> Bugs *in* memory allocation will put you in the cuckoo people place..

>
> >> > Which is why they are exceedingly rare. Nearly all allocation problems are due
> >> > to the program storing outside array bounds.

>
> >> * * *The only allocator bug I have personally encountered was with
> >> a malloc() implementation that never, never returned NULL. *When it
> >> ought to have returned NULL, it crashed the program instead ...

>
> > If you don't provide a way to verify that, it didn't happen ;-), and
> > there was a bug in your code.

>
> I suspect he's referring to the malloc() implementation
> on typical Linux systems, which overcommits memory by default.
> It can allocate a large chunk of address space for which no actual
> memory is available. *The memory isn't actually allocated until
> the process attempts to access it. *If there isn't enough memory
> available for the allocation, the "OOM killer" kills some process
> (not necessarily the one that did the allocation).


That crossed my mind, but what he said doesn't correspond with what
happens: malloc does return something and __doesn't__ crash the
program. OOM killer kills the code upon an attempt to access that
memory.

But given the way he explained it, it's possible that he's affected by
OOM killer, and he forgot, or never knew, what really happened.

Goran.

Eric Sosman 02-17-2012 01:06 PM

Re: malloc
 
On 2/17/2012 2:40 AM, Goran wrote:
> On Feb 17, 2:27 am, Eric Sosman<esos...@ieee-dot-org.invalid> wrote:
>> On 2/16/2012 4:21 PM, Devil with the China Blue Dress wrote:
>>
>>> In article<jhjr14$rj...@reader1.panix.com>, j...@panix.com (Joe keane) wrote:

>>
>>>> Bugs of memory allocation will make you mad.

>>
>>>> Bugs *in* memory allocation will put you in the cuckoo people place.

>>
>>> Which is why they are exceedingly rare. Nearly all allocation problems are due
>>> to the program storing outside array bounds.

>>
>> The only allocator bug I have personally encountered was with
>> a malloc() implementation that never, never returned NULL. When it
>> ought to have returned NULL, it crashed the program instead ...

>
> If you don't provide a way to verify that, it didn't happen ;-), and
> there was a bug in your code.


Yeah, it was probably my code. Awfully nice of DEC to fix it
for me by patching VMS' C library, don't you think?

--
Eric Sosman
esosman@ieee-dot-org.invalid

Joachim Schmitz 02-17-2012 04:05 PM

Re: malloc
 
Noob wrote:
> Eric Sosman wrote:
>
>> The only allocator bug I have personally encountered was with
>> a malloc() implementation that never, never returned NULL. When it
>> ought to have returned NULL, it crashed the program instead ...

>
> Visual Studio 6 used to crash on free(NULL).


Which seems OK, of malloc() never returns NULL.
free() only needs to take what malloc() gives, doesn't it?

Bye, Jojo

PS: ;-)


All times are GMT. The time now is 05:34 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.