Re: Git 2.13.0 segfaults on Solaris SPARC due to DC_SHA1=YesPlease being on by default
- Date: Mon, 15 May 2017 18:09:39 -0400
- From: Jeff King <peff@xxxxxxxx>
- Subject: Re: Git 2.13.0 segfaults on Solaris SPARC due to DC_SHA1=YesPlease being on by default
On Mon, May 15, 2017 at 04:13:58PM +0200, Ævar Arnfjörð Bjarmason wrote:
> On Mon, May 15, 2017 at 3:58 PM, Marc Stevens <marc@xxxxxxxxxxxxxxx> wrote:
> > Hi Aevar,
> > Thank you for notifying us of this issue.
> > Big endianness is a tricky issue, also since I don't have access or accurate knowledge about all big endian systems.
> > Our github repo does check correct functioning, including an endianness mistake, with 'make test'.
> > But I guess this is not included for SHA1DC in Git.
> > Anyway, we can easily add the _BIG_ENDIAN macrotest to the git repo and will do so soon.
> > I don't think the segfault is caused by buffer overflow, inproper access, or the endianness issue.
> > But I did notice an unexpected issue: the message block pointer m=0x398ad5 is odd.
> > Can you confirm whether loading an uint32_t from an odd address triggers a hardware interrupt on your platform?
> > This is not problem for x86, but maybe for your platform it is?
> > If it is then we should always copy buffer contents to the sha1context to avoid this issue.
> I don't have access to the box in question, Michael was testing this
> code for me. But unaligned access is probably the cause, although
> according to some info I found online that should give a SIGBUS not a
> SIGSEGV, but that may have changed:
Yeah, I would have expected SIGBUS there. If we have alignment issues,
though, I'd expect that ARM systems will experience problems.
Block-sha1 uses a macro which allows unaligned loads on platforms that
support it, and otherwise does the endian conversion on the fly as we
load the bytes into a local variable (which presumably happens all
in-register). That may be faster than doing a mass copy of the buffer.