Re: [BUG] Segfault on git describe

2014-03-22 Thread Dragos Foianu
Jeff King peff.net> writes: > > So I think we'd be happy to see it converted to an iterative process > (probably with a stack on the heap). In addition to name-rev, I believe > that "tag --contains" will recurse down the longest history path, too (I > think there may have been experimental patch

Re: [BUG] Segfault on git describe

2014-03-20 Thread Jeff King
On Wed, Mar 19, 2014 at 10:34:29PM +, Dragos Foianu wrote: > The name_rev function recursively calls itself which is why the backtrace is > so big. Unfortunately, for repos with long histories it can lead to Stack > Overflows. This is pretty much what happened in your case. > > I tested it on

Re: [BUG] Segfault on git describe

2014-03-20 Thread Sylvestre Ledru
Sylvestre Ledru mozilla.com> writes: > As attachment, the backtrace. I removed about 87250 calls to the > name_rev function. I guess that is a potential source of problem. FYI, ulimit -s 10 (increase the stack size) fixes the issue. Sylvestre -- To unsubscribe from this list: send the lin

Re: [BUG] Segfault on git describe

2014-03-19 Thread Dragos Foianu
Sylvestre Ledru mozilla.com> writes: > > Hello, > > Trying to do some stats using the Firefox git repository > (https://github.com/mozilla/gecko-dev), I found a bug > on git describe. The following command will segfault: > git describe --contains a9ff31aebd6dbda82a3c733a72eeeaa0b0525b96 > > Pl

[BUG] Segfault on git describe

2014-03-19 Thread Sylvestre Ledru
Hello, Trying to do some stats using the Firefox git repository (https://github.com/mozilla/gecko-dev), I found a bug on git describe. The following command will segfault: git describe --contains a9ff31aebd6dbda82a3c733a72eeeaa0b0525b96 Please note that the Firefox history is a pretty long and th