Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > malloc

Reply
Thread Tools

malloc

 
 
Joe keane
Guest
Posts: n/a
 
      02-16-2012
Bugs of memory allocation will make you mad.

Bugs *in* memory allocation will put you in the cuckoo people place.
 
Reply With Quote
 
 
 
 
BGB
Guest
Posts: n/a
 
      02-16-2012
On 2/16/2012 2:21 PM, Devil with the China Blue Dress wrote:
> In article<jhjr14$rjk$(E-Mail Removed)>, http://www.velocityreviews.com/forums/(E-Mail Removed) (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...

 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      02-17-2012
On 2/16/2012 4:21 PM, Devil with the China Blue Dress wrote:
> In article<jhjr14$rjk$(E-Mail Removed)>, (E-Mail Removed) (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
(E-Mail Removed)d
 
Reply With Quote
 
Goran
Guest
Posts: n/a
 
      02-17-2012
On Feb 17, 2:27*am, Eric Sosman <(E-Mail Removed)> wrote:
> On 2/16/2012 4:21 PM, Devil with the China Blue Dress wrote:
>
> > In article<jhjr14$(E-Mail Removed)>, (E-Mail Removed) (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.
 
Reply With Quote
 
Goran
Guest
Posts: n/a
 
      02-17-2012
On Feb 16, 10:04*pm, (E-Mail Removed) (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.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      02-17-2012
Goran <(E-Mail Removed)> writes:
> On Feb 17, 2:27*am, Eric Sosman <(E-Mail Removed)> wrote:
>> On 2/16/2012 4:21 PM, Devil with the China Blue Dress wrote:
>>
>> > In article<jhjr14$(E-Mail Removed)>, (E-Mail Removed) (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) (E-Mail Removed) <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"
 
Reply With Quote
 
Noob
Guest
Posts: n/a
 
      02-17-2012
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).
 
Reply With Quote
 
Goran
Guest
Posts: n/a
 
      02-17-2012
On Feb 17, 11:26*am, Keith Thompson <(E-Mail Removed)> wrote:
> Goran <(E-Mail Removed)> writes:
> > On Feb 17, 2:27*am, Eric Sosman <(E-Mail Removed)> wrote:
> >> On 2/16/2012 4:21 PM, Devil with the China Blue Dress wrote:

>
> >> > In article<jhjr14$(E-Mail Removed)>, (E-Mail Removed) (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.
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      02-17-2012
On 2/17/2012 2:40 AM, Goran wrote:
> On Feb 17, 2:27 am, Eric Sosman<(E-Mail Removed)> wrote:
>> On 2/16/2012 4:21 PM, Devil with the China Blue Dress wrote:
>>
>>> In article<jhjr14$(E-Mail Removed)>, (E-Mail Removed) (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
(E-Mail Removed)d
 
Reply With Quote
 
Joachim Schmitz
Guest
Posts: n/a
 
      02-17-2012
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:
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
to malloc or not to malloc?? Johs32 C Programming 4 03-30-2006 10:03 AM
porting non-malloc code to malloc micromysore@gmail.com C Programming 3 02-19-2005 05:39 AM
Malloc/Free - freeing memory allocated by malloc Peter C Programming 34 10-22-2004 10:23 AM
free'ing malloc'd structure with malloc'd members John C Programming 13 08-02-2004 11:45 AM
Re: free'ing malloc'd structure with malloc'd members ravi C Programming 0 07-30-2004 12:42 PM



Advertisments