"R. Tyler Ballance" <tyler@xxxxxxxxx> wrote: > 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` > > 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? Look at xmmap in git's code. All of our mmap calls go through that function and try to release pack windows if we get an error back from mmap(), then it retries the mmap request. xmalloc likewise does the same thing for malloc requests; xcalloc for calloc, xstrdup for strdup. We have a number of these x variant functions to handle memory allocation. You might be be able to put a setrlimit call into main() in git.c to drop the rlimit for Git to a lower limit than it inherited from gdb, allowing you to start gdb with a much higher ulimit so it doesn't barf when trying to inspect the git child. -- Shawn. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
