I'm running a wheezy:armhf chroot using qemu user emulation on my jessie:x86_64 system. Somehow, a git clone on a particular repository will hang inside the chroot, while succeed natively. This might be a bug, who knows? To improve my karma, I wanna find out whats going on!

As a side-note: the hang I'm experiencing is occuring with git 2.0 inside jessie:armhf as well... Also using an armel does not change the picture. So I went on digging in the wheezy:armhf rabbithole, just because I had to choose one... I cannot test on a native machine...

There is no git-dbg packet, so I roll my own. Inside the wheezy:armhf chroot:

sudo apt-get install build-essential fakeroot
sudo apt-get build-dep git
apt-get source git && cd git-1.7.10.4
DEB_CFLAGS_APPEND="-fno-stack-protector" DEB_CXXFLAGS_APPEND="-fno-stack-protector" DEB_BUILD_MAINT_OPTIONS=hardening=-stackprotector,-fortify DEB_BUILD_OPTIONS="noopt nostrip nocheck" fakeroot dpkg-buildpackage -j´getconf _NPROCESSORS_ONLN`
sudo dpkg -i ../git_1.7.10.4-1+wheezy1_armhf.deb

As far as I read the gcc-documentation, setting DEB_CFLAGS_APPEND and DEB_CXXFLAGS_APPEND additionally with -fno-stack-protector is not needed, but anyhow, wanna be sure ,-)

Then, using qemu's builtin gdbserver, inside the chroot I'm doing:

QEMU_GDB=1234 git clone /path/to/breaking/repo /tmp/bla

Debugging inside the qemu throws an unsupported syscal 26 error...

Firing up gdb-multiarch outside the chroot, to connect from outside:

gdb-multiarch -q
(gdb) set architecture arm                    # prevents "warning: Architecture rejected target-supplied description"
(gdb) target remote localhost:1234
(gdb) set sysroot /opt/chroots/wheezy:armhf
(gdb) file /opt/chroots/wheezy:armhf/usr/bin/git
Reading symbols from /opt/chroots/wheezy:armhf/usr/bin/git...done. # good! has debug symbols!
(gdb) list                                    # works! code is not stripped
(gdb) step
Cannot find bounds of current function        # meh...
(gdb) backtracke
#0  0xf67e0c90 in ?? ()
#1  0x00000000 in ?? ()                       # wtf?

Giving a continue to let the clone happen will result in a hang, sending a ctrl-c is ignored.

Generating a core-file and loading it into gdb (inside the chroot) will give me a corrupt stack:

gdb -q /usr/bin/git qemu_git_20140514-160951_22373.core
Reading symbols from /usr/bin/git...done.
[New LWP 22373]
Cannot access memory at address 0xf67fe948
Cannot access memory at address 0xf67fe944
(gdb) bt
#0  0xf678b3e4 in ?? ()
#1  0xf678b3d4 in ?? ()
#2  0xf678b3d4 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Now I'm lost.

Where is the problem? Did I miss some detail in the qemu-user-emulation? Do I have to use a completely emulated arm-machine? A misunderstanding in cross-debugging? gdb-multiarch limitations? The creation of debug-packages?

Thanks for any suggestions, pointers, hints, tips or what-not...