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:
signature.asc
Description: This is a digitally signed message part
