by chris.vanhorne:

Tested against release (as of 6/30/10) and tip (6470c731be0).

GOARCH=arm, GOOS=linux, gcc=4.4.3 (Ubuntu 4.4.3-4ubuntu5)

Code running under the ARMv7 architecture [1] compiled with 5g/5l does not exhibit the
same behavior as 386 8g/8l.

Using the simple web server example from golang.org [2], the IP and Port values become
null and 0 when the type is converted from a TCPAddr to sockaddr.

ListenTCP in net/tcpsock.go is passed an instance of type TCPAddr which is then
converted to a sockaddr via the toAddr() call in net/tcpsock.go, but the IP and Port
fields are then null and 0 when entering the toAddr function. This later causes an
allocation loop when attempting to call TCPAddr.String() with null arguments in
net/fd.go:newFD at the following line:
        var ls, rs string
        if laddr != nil {
                ls = laddr.String() // stuck and looped allocation here
        }

With a few rudimentary debugging print statements [3], the differences between the 386
and ARM code can be seen when attempting to run the example Go web server:

386:/tmp$ ./test
net/tcpsock.go:toAddr: a.IP=, a.Port=12345
net/tcpsock.go:sockaddr: a.IP=, a.Port=12345
net/ipsock.go:ipToSockaddr: ip=, port=12345
^C
386:/tmp$

and the ARM execution:
# ./test
net/tcpsock.go:toAddr: a.IP=, a.Port=12345
net/tcpsock.go:sockaddr: a.IP=?, a.Port=0
net/ipsock.go:ipToSockaddr: ip=?, port=0
[1]   Killed                  ./test 
arm#


[1] 
# cat /proc/cpuinfo
Processor       : ARMv7 Processor rev 2 (v7l)
BogoMIPS        : 162.54
Features        : swp half thumb fastmult vfp edsp thumbee neon
CPU implementer : 0x51
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0x00f
CPU revision    : 2


[2] 
package main

import (
       "fmt"
       "http"
)

func handler(c *http.Conn, r *http.Request) {
       fmt.Fprintf(c, "Hi there, I love %s!", r.URL.Path[1:])
}

func main() {
       http.HandleFunc("/", handler)
       http.ListenAndServe(":8080", nil)
}


[3] Attached diff with print debugging

Attachments:

1. debug1.diff (1187 bytes)