On Wed, Oct 19, 2016 at 08:47:50PM +0700, Duy Nguyen wrote: > On Wed, Oct 19, 2016 at 08:27:43PM +0700, Duy Nguyen wrote: > > If you set the environment variable GIT_ALLOC_LIMIT ... git > > attempts to allocate more than that ... then it's caught and we get > > a glimpse of how much memory git may need. Unfortunately we can't > > get a stack trace or anything like that unless you rebuild Git from > > source. > > It's moments like this that I wish we had a knob to force core > dumps. And I often modify die_builtin() to add '*(char*)0 = 1;' to > force a core dump when I can't figure out some problem based on the > error message alone. > > So.. how about we do something like this? We could extend it to abort > on error() as well as die(). Aborting on warning() may be a bit too > much though. On glibc systems we could even print the back trace > without aborting, which helps in some cases. I have been tempted by something like this, too, and have occasionally resorted to patching in an abort() call to get cores from sub-processes. I'm not sure how useful it would be in practice in deployed versions of git, though. You'd have to coach the user into finding the core file and generating the backtrace from it. Something that called backtrace(3) automatically would be more seamless (but provides worse information than gdb), and otherwise it is probably just as easy to ship the user cut-and-paste instructions to use gdb. See the previous discussion in this subthread: http://public-inbox.org/git/20150424201734.GA4747@xxxxxxxx/T/#u -Peff