Odd git overrflow bug?

We have an odd bug report in the kernel, where somebody had trouble bisecting all the way due to

  "git is failing with "you are trying to use to much memory"(?!)"

which can't be an exact error message quote, but the closest I can find smells like the "unsigned_add_overflows()" check in the strbuf code. Very odd.

See

    https://bugzilla.kernel.org/show_bug.cgi?id=121701

for the bug report.

I'm not seeing how that could *possibly* happen, but if it indeed is that strbuf code, maybe it could print out the function name (there are two different cases) and values so give a hint about where/how this happens..

Of course, since the bug report isn't an exact quote anyway, maybe that wouldn't have helped anyway. I asked for more information.

           Linus

Linus Torvalds <torvalds@linux-foundation.org> writes:

I've seen that too, but only at the end of bisection, when it tries to display the bad commit.

For example, when running git bisect on git://gcc.gnu.org/git/gcc:

$ git bisect start de4fa746271d39d490b59bdfbbdd2cf5b54c0521 dd58bf212e9a250300e64d78748418b01d0035cd
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[f529d395184700e2404f4a293a2198355ab7ded5] Daily bump.
$ git bisect good
de4fa746271d39d490b59bdfbbdd2cf5b54c0521 is the first bad commit
commit de4fa746271d39d490b59bdfbbdd2cf5b54c0521
fatal: you want to use way too much memory

Andreas.

On Sun, Jul 10, 2016 at 11:41 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:

That's apparently what the kernel bug reporter sees too now.

However, I cannot reproduce the problem with the particular kernel bisect that the reporter is using. Judging by what he bisected things down to, he must have done

    git bisect start
    git bisect bad 7ed18e2d1b6782989eb399ef79a8cc1a1b583b3c
    git bisect good 7ed18e2d1b6782989eb399ef79a8cc1a1b583b3c^
    git bisect good
    git bisect bad

but that works fine for me.

[ Oops. I tested something. It works for me with current git, but with git-2.9.0 I get the failure ].

I'll try to figure out why git-2.9.0 fails.

               Linus

On Sun, Jul 10, 2016 at 2:01 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:

I'm getting "extra" being -1 in strbuf_grow(). Let me dog deeper.

           Linus

On Sun, Jul 10, 2016 at 2:05 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:

"dog deeper"? My typing skills are deteriorating.

Anyway, I dug deeper, and the reason is that "tabwidth" is -1, and then

 pretty.c:1669: strbuf_add_tabexpand():

        strbuf_addchars(sb, ' ', tabwidth - (width % tabwidth));

ends up having the number be -1.

I'm not sure why it doesn't happen in current git master, because that function is the same, and the logic around expand_tabs_in_log looks similar too.

That all came from

    fe37a9c586a6 (:pretty: allow tweaking tabwidth in --expand-tabs")

and I suspect the code just needs to protect against negative or zero, rather than just zero.

Junio?

              Linus

On Sun, Jul 10, 2016 at 2:21 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:

Ahh. Commit 43ec55091553 ("bisect: always call setup_revisions after init_revisions") is in master, but not in v2.9.0

            Linus

On Sun, Jul 10, 2016 at 2:29 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:

Yes, leaving it in 'master' a while and then merging it down to 'maint' for v2.9.x series is the plan as usual. Thanks for noticing and following up.