Thread (3 messages) flat view 3 messages, 2 authors, 2016-06-15

Re: [PATCHv3] refs.c: enable large transactions

From: Jeff King <hidden>
Date: 2016-06-15 23:04:32

On Sat, Apr 25, 2015 at 01:00:58AM -0400, Jeff King wrote:
A better solution to what I proposed earlier is perhaps:

  git config alias.debug '!gdb --quiet \
	    -ex "break exit" \
	    -ex "run" \
	    -ex "bt full" \
	    -ex "continue" \
	    -ex "quit" \
	    --args git \
  '
  git debug rev-parse foobar

It has the minor irritation that gdb will control the process stdio
(slurping from stdin and polluting stdout, whereas we would prefer no
input and output to stderr). There might be a way to convince gdb to do
otherwise, or you could probably go pretty far with some shell fd
redirects and using "set args" inside gdb. Or maybe something with
gdbserver.
Just to extend the thought exercise, here is something marginally less
horrible. Save as "git-debug" in your PATH and chmod +x.

-- >8 --
#!/bin/sh

if ! type gdb >/dev/null 2>&1; then
	echo >&2 "Sorry, you don't seem to have gdb installed."
	exit 1
fi

args=
for i in "$@"; do
	args="$args '$(printf '%s' "$i" | sed "s/'/'\\\\''/")'"
done

gdb --quiet \
	-ex "set args $args <&7 >&8 2>&9" 7<&0 8>&1 9>&2 </dev/null >&2 \
	-ex 'break exit' \
	-ex 'run' \
	-ex 'bt full' \
	-ex 'continue' \
	-ex 'quit' \
	git
-- 8< --

It's still rather hard to use with sub-programs started by git (e.g.,
the upload-pack spawned by a fetch), but I think it would work for many
simple cases. I'm not sure if I would use it myself. As somebody
confident in using gdb, my next step after seeing the backtrace would be
to start poking around interactively. Besides the stdio magic, this is
not really buying me much beyond running gdb myself.

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help