segfault in tc/checkout-B

Tue, 10 Aug 2010 01:01:43 +0800 | Filed under git

Today, while using my git checkout -B feature, I stumbled on a spectacular segfault.

However, gdb tracebacks on cygwin are terribly useless. Here's my gdb session:

$ gdb --args ./git --exec-path=. checkout -B rc/master
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) run
Starting program: /cygdrive/F/Files/coding/git/git/git --exec-path=. checkout -B rc/master
[New thread 3116.0x1168]
[New thread 3116.0xa38]
[New thread 3116.0x8ac]
[New thread 3116.0x1340]
      2 [main] git 3116 exception::handle: Exception: STATUS_ACCESS_VIOLATION

Program received signal SIGTRAP, Trace/breakpoint trap.
0x7c90120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) bt
#0  0x7c90120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1  0x61006345 in break_here () from /usr/bin/cygwin1.dll
#2  0x61027358 in try_to_debug () from /usr/bin/cygwin1.dll
#3  0x61028a9d in exception::handle () from /usr/bin/cygwin1.dll
#4  0x7c9032a8 in ntdll!RtlCopyOutOfProcessMemoryStreamTo () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#5  0x0023932c in ?? ()
#6  0x0023ff70 in ?? ()
#7  0x00239348 in ?? ()
#8  0x00239300 in ?? ()
#9  0x0023ff70 in ?? ()
#10 0x61028740 in sigpacket::process () from /usr/bin/cygwin1.dll
#11 0x7c90327a in ntdll!RtlCopyOutOfProcessMemoryStreamTo () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#12 0x0023932c in ?? ()
#13 0x0023ff70 in ?? ()
#14 0x00239348 in ?? ()
#15 0x00239300 in ?? ()
#16 0x61028740 in sigpacket::process () from /usr/bin/cygwin1.dll
#17 0x7c90e48a in ntdll!LdrDisableThreadCalloutsForDll () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#18 0x00000000 in ?? ()

So, I had to re-run it on my Ubuntu VM. Luckily, this issue was easily reproduced - it's caused by running the command from a detached HEAD.

Apparently strcmp() can't handle null values. (cue eye roll)

The fix is out here.