Re: pkg/49490: "hg clone" does not work on big endian machines

[David Holland <dholland-pbugs%netbsd.org@localhost>]

The following reply was made to PR pkg/49490; it has been noted by GNATS.

From: David Holland <dholland-pbugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: pkg/49490: "hg clone" does not work on big endian machines
Date: Thu, 15 Jan 2015 19:29:30 +0000

 (not sent to gnats)
 
    ------
 
 From: Christos Zoulas <christos%astron.com@localhost
 To: pkgsrc-bugs%NetBSD.org@localhost
 Subject: Re: pkg/49490: "hg clone" does not work on big endian machines
 Date: Sat, 10 Jan 2015 23:47:01 +0000 (UTC)
 
 In article <20150110201501.26744A65BA%mollari.NetBSD.org@localhost>,
 Martin Husemann  <gnats-bugs%NetBSD.org@localhost> wrote:
 >The following reply was made to PR pkg/49490; it has been noted by GNATS.
 >
 >From: Martin Husemann <martin%duskware.de@localhost>
 >To: gnats-bugs%NetBSD.org@localhost
 >Cc: 
 >Subject: Re: pkg/49490: "hg clone" does not work on big endian machines
 >Date: Sat, 10 Jan 2015 21:14:40 +0100
 >
 > I traced the network traffic while taking a ktrace at the same time,
 > all running with a slightly modified py-mercurial, that would invoke
 > the python debugger once the problem happens - and also doing
 > hg --debug clone ...
 > 
 > If needed I can make the (significantly larger) full traces available, the
 > relevant tail of both is here:
 > 
 > http://www.netbsd.org/~martin/hg-clone-pcap.tar.bz2 (2.3 MB)
 > 
 > It seems the actual 0 byte return comes from a recvfrom(), the socket
 > connected to the http port seems to be fd 4:
 > 
 >  12647      1 python2.7 CALL  recvfrom(4,0xfffffffff60ae024,0x6a12,0,0,0)
 >  12647      1 python2.7 MISC  msghdr: [name=0x0, namelen=0,
 >iov=0x1b2915cc0, iovlen=1, control=0x0, controllen=0, flags=0]
 >  12647      1 python2.7 GIO   fd 4 read 0 bytes
 >        ""
 >  12647      1 python2.7 RET   recvfrom 0
 >  12647      1 python2.7 CALL  recvfrom(4,0xfffffffff60ae024,0x6a12,0,0,0)
 >  12647      1 python2.7 MISC  msghdr: [name=0x0, namelen=0,
 >iov=0x1b2915cc0, iovlen=1, control=0x0, controllen=0, flags=0]
 >  12647      1 python2.7 GIO   fd 4 read 0 bytes
 >        ""
 >  12647      1 python2.7 RET   recvfrom 0
 > 
 > [..]
 > and this imediately leeds to:
 > 
 >  12647      1 python2.7 CALL  write(2,0xfffffffff64f16e4,0x13)
 >  12647      1 python2.7 GIO   fd 2 wrote 19 bytes
 >        "transaction abort!\n"
 
 What happens on the sender side?
 
 christos