[Gc] GC_allochblk_nth bug

Hans Boehm Hans.Boehm at hp.com
Sun Mar 9 11:32:54 PST 2008

My feeling here is that

a) Allocations this large are certainly not recommended.

b) This should not result in a segmentation fault.  The fact that it does 
worries me a bit, in that there might be a way to turn this into a 
security hole.

I'm testing a patch, together with a new test case.  The patch should 
cause it to fail with an out-of-memory return.


On Mon, 3 Mar 2008, Roger Osborn wrote:

> Bruce Hoult wrote:
>> On Mon, Mar 3, 2008 at 2:19 PM, Romano Tenca <rotenca at gmail.com> wrote:
>>> I have a segmentation fault if i add these lines to gctest soon after
>>>  GC_INIT()
>>>      GC_expand_hp(1024*1024*5);
>>>      void *r = GC_MALLOC(2147483647-1024);
>> Does anyone else think it's just fundamentally a bad idea to use such
>> a large portion of the address space for a conservative garbage
>> collector's heap?
>> _______________________________________________
> We have a program that's grown into being in that position on Windows.
> It does seem to lead to very high page fault rates as you approach the
> point of memory exhaustion, but that's probably inevitable given our
> pattern of allocations. I think the GC FAQ documentation mentions
> somewhere that it behaves acceptably in this area for some applications,
> and not others. So far we've considered the convenience makes it worth
> having, and we do try and assist by using GC_MALLOC_ATOMIC where
> appropriate.
> In fact GC doesn't get the whole address space in our case, because some
> of our code uses GC and some the traditional Windows memory management
> (especially that code which is in third party libraries). We have found
> (by dumping Windows heaps) that GC often can't get a large chunk (up to
> 400-500Mb) of the address space because one of the heaps has reserved
> (but not committed) that region of the address space already. This can
> lead to the program giving up prematurely because the "wrong" memory
> manager has the remaining space.  Wonder if anyone here has worked round
> that problem, e.g. by finding away of letting GC manage everything?
> I've done that sort of plumbing in Debug build mode using
> _CrtSetAllocHook in the past, but don't know if it's even possible in
> Release mode.
> Thanks,
> Roger
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list