The sh1dc implementation is making unaligned accesses, which will crash
on some architectures, others have to emulate them in software.
Breakpoint 4, sha1_compression_states (ihv=0x600e7010,
m=, W=0x600e70a8, states=0x600e7328)
at sha1dc/sha1.c:398
398
SHA1DCUpdate calls sha1_process with buf being unaligned.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Is this with or without a0103914 ("sha1dc: update from upstream",
2017-05-20)?
This is git 2.13.0.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
On Thu, Jun 01, 2017 at 10:28:52AM +0200, Andreas Schwab wrote:
> The sh1dc implementation is making unaligned accesses, which will crash
> on some architectures, others have to emulate them in software.
>
> Breakpoint 4, sha1_compression_states (ihv=0x600e7010,
> m=, W=0x600e
> On 01 Jun 2017, at 10:28, Andreas Schwab wrote:
>
> The sh1dc implementation is making unaligned accesses, which will crash
> on some architectures, others have to emulate them in software.
Is SPARC an architecture that would run into this problem? I think
there was a thread a few days ago ab
On Jun 01 2017, "brian m. carlson" wrote:
> On Thu, Jun 01, 2017 at 10:28:52AM +0200, Andreas Schwab wrote:
>> The sh1dc implementation is making unaligned accesses, which will crash
>> on some architectures, others have to emulate them in software.
>>
>> Breakpoint 4, sha1_compression_states (i
Andreas Schwab writes:
> This is git 2.13.0.
Thanks. It is a known issue with a known fix cooking in 'next' to
be merged down to 'master' and 'maint' not in a too distant future.
An extra testing to ensure that the "fix" actually works before it
is merged down to a maintenance release is very m
Lars Schneider writes:
>> On 01 Jun 2017, at 10:28, Andreas Schwab wrote:
>>
>> The sh1dc implementation is making unaligned accesses, which will crash
>> on some architectures, others have to emulate them in software.
>
> Is SPARC an architecture that would run into this problem? I think
> the
On Jun 01 2017, Junio C Hamano wrote:
> Depending on the model of "ARM" (or "SPARC") emulated with QEMU, and
> depending on the OS that runs on such an "ARM" or "SPARC", we may
> not see this---if the emulated OS has the "software unaligned-access
> emulation" our userland may not see a SIGBUS.
On 1 June 2017 at 12:08, Andreas Schwab wrote:
> On Jun 01 2017, Junio C Hamano wrote:
>
>> Depending on the model of "ARM" (or "SPARC") emulated with QEMU, and
>> depending on the OS that runs on such an "ARM" or "SPARC", we may
>> not see this---if the emulated OS has the "software unaligned-ac
On Thu, Jun 1, 2017 at 12:26 PM, Martin Ågren wrote:
> On 1 June 2017 at 12:08, Andreas Schwab wrote:
>> On Jun 01 2017, Junio C Hamano wrote:
>>
>>> Depending on the model of "ARM" (or "SPARC") emulated with QEMU, and
>>> depending on the OS that runs on such an "ARM" or "SPARC", we may
>>> not
On 1 June 2017 at 12:33, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Jun 1, 2017 at 12:26 PM, Martin Ågren wrote:
>> On 1 June 2017 at 12:08, Andreas Schwab wrote:
>>> Even if the architecture implements unaligned accesses in hardware, it
>>> is still undefined behaviour, and the compiler will (eve
On 1 June 2017 at 13:53, Martin Ågren wrote:
> On 1 June 2017 at 12:33, Ævar Arnfjörð Bjarmason wrote:
>> On Thu, Jun 1, 2017 at 12:26 PM, Martin Ågren wrote:
>>> On 1 June 2017 at 12:08, Andreas Schwab wrote:
Even if the architecture implements unaligned accesses in hardware, it
is s
Martin Ågren writes:
> I looked into this some more. It turns out it is possible to trigger
> undefined behavior on "next". Here's what I did:
> ...
>
> This "fixes" the problem:
> ...
> diff --git a/sha1dc/sha1.c b/sha1dc/sha1.c
> index 3dff80a..d6f4c44 100644
> --- a/sha1dc/sha1.c
> +++ b/sha1d
On Fri, Jun 2, 2017 at 2:15 AM, Junio C Hamano wrote:
> Martin Ågren writes:
>
>> I looked into this some more. It turns out it is possible to trigger
>> undefined behavior on "next". Here's what I did:
>> ...
>>
>> This "fixes" the problem:
>> ...
>> diff --git a/sha1dc/sha1.c b/sha1dc/sha1.c
>>
On 2 June 2017 at 10:51, Ævar Arnfjörð Bjarmason wrote:
> On Fri, Jun 2, 2017 at 2:15 AM, Junio C Hamano wrote:
>> Martin Ågren writes:
>>
>>> I looked into this some more. It turns out it is possible to trigger
>>> undefined behavior on "next". Here's what I did:
>>> ...
>>>
>>> This "fixes" th
* ?var Arnfj?r? Bjarmason [170602 04:53]:
> On Fri, Jun 2, 2017 at 2:15 AM, Junio C Hamano wrote:
> > Martin Ågren writes:
> >
> >> I looked into this some more. It turns out it is possible to trigger
> >> undefined behavior on "next". Here's what I did:
> >> ...
> >>
> >> This "fixes" the probl
On Fri, Jun 2, 2017 at 4:46 PM, Liam R. Howlett wrote:
> * ?var Arnfj?r? Bjarmason [170602 04:53]:
>> On Fri, Jun 2, 2017 at 2:15 AM, Junio C Hamano wrote:
>> > Martin Ågren writes:
>> >
>> >> I looked into this some more. It turns out it is possible to trigger
>> >> undefined behavior on "next
On Fri, Jun 2, 2017 at 11:49 AM, Martin Ågren wrote:
> On 2 June 2017 at 10:51, Ævar Arnfjörð Bjarmason wrote:
>> On Fri, Jun 2, 2017 at 2:15 AM, Junio C Hamano wrote:
>>> Martin Ågren writes:
>>>
I looked into this some more. It turns out it is possible to trigger
undefined behavior
On 2 June 2017 at 21:32, Ævar Arnfjörð Bjarmason wrote:
> On Fri, Jun 2, 2017 at 11:49 AM, Martin Ågren wrote:
>> On 2 June 2017 at 10:51, Ævar Arnfjörð Bjarmason wrote:
>>> On Fri, Jun 2, 2017 at 2:15 AM, Junio C Hamano wrote:
Martin Ågren writes:
> I looked into this some more.
On Fri, Jun 2, 2017 at 10:11 PM, Martin Ågren wrote:
> On 2 June 2017 at 21:32, Ævar Arnfjörð Bjarmason wrote:
>> On Fri, Jun 2, 2017 at 11:49 AM, Martin Ågren wrote:
>>> On 2 June 2017 at 10:51, Ævar Arnfjörð Bjarmason wrote:
On Fri, Jun 2, 2017 at 2:15 AM, Junio C Hamano wrote:
> Ma
On 2 June 2017 at 21:32, Ævar Arnfjörð Bjarmason wrote:
> On Fri, Jun 2, 2017 at 11:49 AM, Martin Ågren wrote:
>> On 2 June 2017 at 10:51, Ævar Arnfjörð Bjarmason wrote:
>>> On Fri, Jun 2, 2017 at 2:15 AM, Junio C Hamano wrote:
Martin Ågren writes:
> I looked into this some more.
On 2 June 2017 at 22:14, Ævar Arnfjörð Bjarmason wrote:
> On Fri, Jun 2, 2017 at 10:11 PM, Martin Ågren wrote:
>> On 2 June 2017 at 21:32, Ævar Arnfjörð Bjarmason wrote:
>>> On Fri, Jun 2, 2017 at 11:49 AM, Martin Ågren
>>> wrote:
On 2 June 2017 at 10:51, Ævar Arnfjörð Bjarmason wrote:
>
On Fri, Jun 2, 2017 at 10:17 PM, demerphq wrote:
> On 2 June 2017 at 21:32, Ævar Arnfjörð Bjarmason wrote:
>> On Fri, Jun 2, 2017 at 11:49 AM, Martin Ågren wrote:
>>> On 2 June 2017 at 10:51, Ævar Arnfjörð Bjarmason wrote:
On Fri, Jun 2, 2017 at 2:15 AM, Junio C Hamano wrote:
> Martin
On Fri, Jun 2, 2017 at 1:17 PM, demerphq wrote:
> Most hash function implementations have code like the following
> (extracted and reduced from hv_macro.h in perl.git [which only
> supports little-endian hash functions]):
Yes.
Please do *not* try to make things overly portable by adding random
m
Linus Torvalds writes:
> Dereferencing an unaligned pointer may be "undefined" in some
> technical meaning, but it sure as hell isn't undefined in reality, and
> compilers that willfully do stupid things should not be catered to
> overly. Reality is a lot more important.
Thanks for succinctly pu
Ævar Arnfjörð Bjarmason writes:
> On Fri, Jun 2, 2017 at 4:46 PM, Liam R. Howlett
> wrote:
>
>> 2.13.0 is very much broken for me on SPARC.
>> {maint//git} $ make -j120
>> [...]
>> {maint//git} $ ./git log
>> [1]1004506 bus error (core dumped) ./git log
>>
>> This is with b06d36431 (maint)
28 matches
Mail list logo
