Re: [BUG] Core dump w/ bus error on bad mmap'd packfile

From: Thomas Rast <tr@thomasrast.ch>
Date: Dec 3, 2013, 19:50 UTC
Message-ID: <87vbz5n27k.fsf@linux-1gf2.Speedport_W723_V_Typ_A_1_00_098>
In-Reply-To: <CAFGOX=WsGqmgxps64mWKPJ_Anj0tNTz8nQwpyDOpfCVQ_5HXow@mail.gmail.com>

Amit Bakshi <ambakshi@gmail.com> writes:

>  I was getting core dumps (bus error 7) with git 1.7.1 when doing a
> git checkout. I tried git fsck, and same thing. I got the same with
> precompiled rpms of 1.7.12, and with a locally compiled version of git
> 1.8.5.

[...]

Show 10 quoted lines

> $ git fsck
> Checking pack-0ccb5ee4f60003a7ea47d6904633cce5973efa60.pack
> in: 0x7f9070507000 remain: 17345210 offset: 17345230
> Bus error (core dumped)
>
> git verify-pack correctly shows the error, without a bus error.
>
> $ git verify-pack -v pack-0ccb5ee4f60003a7ea47d6904633cce5973efa60.pack
> fatal: read error on input: Input/output error
> pack-0ccb5ee4f60003a7ea47d6904633cce5973efa60.pack: bad

mmap()ing a file and attempting to read from parts that the kernel can then not page in (in your case because it couldn't read the file) are expected to give a SIGBUS, so there is no bug here. The different behavior comes from some commands using mmap() and some using read() to access the packs.

Perhaps we could try to map the faulting address back to the file it came from, though. The siginfo_t for a SIGBUS contains information about the faulting address, so for the case of packs we could walk the 'struct packed_git' list and see which open window the address belongs to. I need to think about the implications of doing that in a signal handler, though.

-- 
Thomas Rast
tr@thomasrast.ch