Re: [PATCH] read-cache: fix division by zero core-dump
- Date: Fri, 28 Sep 2018 16:31:13 +0100
- From: Ramsay Jones <ramsay@xxxxxxxxxxxxxxxxxxxx>
- Subject: Re: [PATCH] read-cache: fix division by zero core-dump
On 28/09/18 02:20, Ben Peart wrote:
> On 9/27/2018 6:24 PM, Ramsay Jones wrote:
>> commit 225df8a468 ("ieot: add Index Entry Offset Table (IEOT)
>> extension", 2018-09-26) added a 'DIV_ROUND_UP(entries, ieot_blocks)
>> expression, where ieot_blocks was set to zero for a single cpu
>> platform. This caused an SIGFPE and a core dump in practically
>> every test in the test-suite, until test t4056-diff-order.sh, which
>> then went into an infinite loop!
>> Signed-off-by: Ramsay Jones <ramsay@xxxxxxxxxxxxxxxxxxxx>
>> Hi Ben,
>> Could you please squash this into the relevant commits on your
>> 'bp/read-cache-parallel' branch. (The first hunk fixes a sparse
>> warning about using an integer as a NULL pointer).
> Absolutely - thanks for the patch.
> I don't know how long it's been since I've been on a single core CPU - I'm sad for you. ;-)
Heh, don't be - whilst I do still have a single cpu laptop about
the place _somewhere_, I haven't booted it up in about 15 years! :-D
I used to regularly test git (and other software) on my old 32-bit
laptop (windows xp/Linux Mint 17.x, Core2 duo), but just lately
I have taken to using a 32-bit VM on my current laptop (4th gen i5)
instead. (The git test-suite would take approx 50 min to run on
the 32-bit hardware, whereas it only takes 8 min on the VM!).
I have configured the 32-bit VM with a single cpu, because when
the VM was configured with two cpus the git test-suite would take
longer to run (approx. 8 -> 10 min)! Taking more resources from
the host, but increasing the running time, didn't seem like a good
Also, this is not the first time some multi-threaded code in git
has 'failed' by assuming more than one cpu, so ...