Re: final git bisect step leads to: "fatal: you want to use way too much memory"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 16, 2016 at 03:29:52PM +0200, Markus Trippelsdorf wrote:

> On 2016.06.16 at 14:53 +0200, Markus Trippelsdorf wrote:
> > markus@x4 gcc % git bisect good
> > f216419e5c4c41df70dbe00a6ea1faea46484dc8 is the first bad commit
> > commit f216419e5c4c41df70dbe00a6ea1faea46484dc8
> > fatal: you want to use way too much memory
> > markus@x4 gcc % 
> 
> The issue started with:
> 
> commit fe37a9c586a65943e1bca327a1bbe1ca4a3d3023
> Author: Junio C Hamano <gitster@xxxxxxxxx>
> Date:   Tue Mar 29 16:05:39 2016 -0700
> 
>     pretty: allow tweaking tabwidth in --expand-tabs

Interesting. But `git show` on the commit in question (f216419e5) does
not have any problems. It looks like bisect's internal "show the commit"
code does not properly call setup_revisions() to finalize the "struct
rev_info". That leaves the expand_tabs_in_log flag as "-1", which then
ends up cast to an unsigned of 2^64 when we use it in a size
computation.

And who knows what other bugs have been lurking there over the years;
there are other flags that should be finalized by setup_revision(), too.

This patch should fix it.

diff --git a/bisect.c b/bisect.c
index 6d93edb..dc13319 100644
--- a/bisect.c
+++ b/bisect.c
@@ -890,6 +890,7 @@ static void show_diff_tree(const char *prefix, struct commit *commit)
 	if (!opt.diffopt.output_format)
 		opt.diffopt.output_format = DIFF_FORMAT_RAW;
 
+	setup_revisions(0, NULL, &opt, NULL);
 	log_tree_commit(&opt, commit);
 }
 
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]