Git crash on EABI system.

[Andrew Turner]

On Thu, 16 May 2013 05:04:29 -0400
Tim Kientzle <kientzle at freebsd.org> wrote:

> 
> On May 16, 2013, at 4:19 AM, Werner Thie wrote:
> 
> >> Has anyone else seen this from git on a clang/EABI system?
> >> 
> >> Assertion failed: (attr_stack->origin), function
> >> prepare_attr_stack, file attr.c, line 630.
> >> 
> >> Program received signal SIGABRT, Aborted.
> >> [Switching to Thread 20c03300 (LWP 100076/git)]
> >> 0x204b842c in thr_kill () from /lib/libc.so.7
> >> (gdb) bt
> >> #0  0x204b842c in thr_kill () from /lib/libc.so.7
> >> #1  0x2044157c in raise () from /lib/libthr.so.3
> >> #2  0x20598130 in abort () from /lib/libc.so.7
> >> #3  0x20574630 in __assert () from /lib/libc.so.7
> >> #4  0x00076b28 in ?? ()
> >> 
> >> I'm planning to do a debug build and see if I can track down any
> >> more details.
> > 
> > Hi Tim
> > 
> > just built git out of curiosity after your post on the BBone
> > 
> > FreeBSD beaglebone 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r250144M:
> > Sat May  4 14:18:20 CEST 2013
> > root at xtools:/usr/home/wthie/proj/crochet-freebsd/work/obj/arm.armv6/usr/local/src/sys/BEAGLEBONE-NOWITNESS
> > arm
> > 
> > git crashes exactly as advertised when cloning a project in
> > 
> > Assertion failed: (attr_stack->origin), function
> > prepare_attr_stack, file attr.c, line 630.
> 
> Thanks for verifying that.
> 
> Unfortunately, a debug build (make -DWITH_DEBUG) does
> not crash for me.  So I clearly have more work ahead of me
> to narrow this down.

I've tracked down the bug to clang/llvm generating
incorrect code for a loop in collect_all_attrs in attr.c.

The first loop in the function looks in a string for the last '/' with
data after it. It appears clang/llvm is generating code that, when there
is a '/', the last_slash value points at an invalid address. When I've
looked at it the value is within the kernel address range.

The code then calculates the length of the directory part of the
string, i.e. the offset of this slash. As the location of this slash is
(incorrectly) found to be a long way from the start of the string, and
the resulting type is a signed int, the value is negative. This will
cause a negative value to be passed into prepare_attr_stack for the
directory length.

prepare_attr_stack has a check to get out of the loop where it checks
the output of strlen against this directory length. As the lengths of
the strings passed to it are small enough such that, when stored in a
signed int, they are all positive, this comparison is always false.
This causes the loop to exit when attr_stack->origin is NULL, causing
the assertion failure.

What needs to be done is to track down why clang/llvm is creating
incorrect code for the loop in collect_all_attrs.

Andrew