Re: [PATCH] Add support for changing packed_git_window_size at process start time

["R. Tyler Ballance" <tyler@slide.com>]

[-- Attachment #1: Type: text/plain, Size: 1772 bytes --]

On Sun, 2008-12-21 at 14:28 -0800, Shawn O. Pearce wrote:
> 
> I think this is a good idea, trying to fit within the ulimit
> rather than assuming we can take whatever we please.  But you
> also need to drop the packed_git_limit down.
> 
> My suggestion is this:
> 
> 	packed_git_limit = as->rlim_cur * 0.85;
> 	packed_git_window_size = packed_git_limit / 4;
> 
> or maybe / 2.  You really want at least 2 windows available within
> your limit.

Ah, gotcha, sounds like a good idea. I went ahead and added the change
and I'm still getting the memory issues. 

I'm not as familiar with using gdb(1), so I'm having trouble tracking
down the issue in a limited session, I get loads of issues like the
following when trying to step through an execution of `git log`


        1368            if (diff_setup_done(&revs->diffopt) < 0)
        (gdb) 
        utils.c:1065: internal-error: virtual memory exhausted: can't
        allocate 4064 bytes.
        A problem internal to GDB has been detected,
        further debugging may prove unreliable.
        Quit this debugging session? (y or n) n
        utils.c:1065: internal-error: virtual memory exhausted: can't
        allocate 4064 bytes.
        A problem internal to GDB has been detected,
        further debugging may prove unreliable.
        Create a core file of GDB? (y or n) y
        (gdb) q
        The program is running.  Quit anyway (and kill it)? (y or n) y
        tyler@starfruit:~/source/git/main>


Is there a means in which I can cause a core dump on an ENOMEM error passed back from mmap(2)? That or a way to impose these limits on the gdb git-subprocess but not on the gdb process?

Appreciate the help :)


Cheers
-- 
-R. Tyler Ballance
Slide, Inc.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]