Hi Michael!
On 12/23/18 8:46 PM, Michael Cree wrote:
>> static inline u64bits _ioa_ntoh64(u64bits v)
>> {
>> #if BYTE_ORDER == LITTLE_ENDIAN
>> u08bits *src = (u08bits*) &v;
>> u08bits* dst = src + 7;
>> while (src < dst) {
>> u08bits vdst = *dst;
>>
On Sun, Dec 23, 2018 at 10:12:27AM +0100, John Paul Adrian Glaubitz wrote:
> On 12/23/18 10:03 AM, wf...@niif.hu wrote:
> > Thanks to everybody for their spot-on comments, and especially to Steve
> > for his detailed analysis in the bug report. Meanwhile I reproduced the
> > error on the sparc64 p
Hello!
I ran the binary through gdb on sparc64 and my backtrace looks
like this:
(gdb) bt
#0 0x0100d0e0 in encode_oauth_token_gcm (server_name=0x7feebd8
"blackdow.carleon.gov", etoken=0x7fee4b8, key=0x7fee100,
dtoken=0x7fedbf0,
nonce0=0x7feeb78 "h4j3k2l2n4b5")
Hi!
On 12/23/18 10:03 AM, wf...@niif.hu wrote:
> Thanks to everybody for their spot-on comments, and especially to Steve
> for his detailed analysis in the bug report. Meanwhile I reproduced the
> error on the sparc64 porterbox, but I couldn't really make head or tail
> of the issue at the source
Steve McIntyre writes:
> That buildd (arm-arm-01) is an arm64 (ARMv8) machine configured to
> build armhf too. Unlike the older AMRv7 systems we'v been using to
> build armhf thus far, the kernel will not fix up user-space alignment
> bugs.
>
> I filed a bug about this exact issue in coturn a cou
5 matches
Mail list logo
