Issue 1:
by russel.winder:

Using HEAD as of 2010-06-26 09:00+01:00 on a Lenovo T500:

|> env | grep '^GO'
GOOGLETEST_HOME=/home/users/russel/lib.Linux.x86_64/GoogleTest
GOBIN=/home/Checkouts/Mercurial/Go/bin_Linux_x86_64
GOARCH=amd64
GOROOT=/home/Checkouts/Mercurial/Go
GOOS=linux
|> hg identify
d02e9053b27d+ tip
|>

Runnin Ubuntu Lucid up to date of the same time all the tests complete correctly.
Running Debian Squeeze up to date of the same time on the exact same hardware, the
network tests result in:

/home/Checkouts/Mercurial/Go/bin_Linux_x86_64/6g -o _gotest_.6 chunked.go client.go
dump.go fs.go lex.go persist.go request.go response.go server.go status.go transfer.go
url.go client_test.go lex_test.go readrequest_test.go request_test.go
requestwrite_test.go response_test.go responsewrite_test.go url_test.go
rm -f _test/http.a
/home/Checkouts/Mercurial/Go/bin_Linux_x86_64/gopack grc _test/http.a _gotest_.6
make[2]: Leaving directory `/home/Checkouts/Mercurial/Go/src/pkg/http'
--- FAIL: http.TestClient
Get http://www.google.com/robots.txt: dial tcp www.google.com:http: dial udp 213.165.231.69:53: network is unreachable
panic: runtime error: invalid memory address or nil pointer dereference

panic PC=0x2b1c521fe368
runtime.panic+0x7c /home/Checkouts/Mercurial/Go/src/pkg/runtime/proc.c:1012
runtime.panic(0x2b1c00000000, 0x405faf)
panicstring+0x60 /home/Checkouts/Mercurial/Go/src/pkg/runtime/runtime.c:83
panicstring(0x49b4f8, 0x2b1c5221c770)
sigpanic+0x84 /home/Checkouts/Mercurial/Go/src/pkg/runtime/linux/thread.c:285
sigpanic()
http.TestClientHead+0xe4 /home/Checkouts/Mercurial/Go/src/pkg/http/client_test.go:37
http.TestClientHead(0x2b1c522189c0, 0x2b1c5221c6f0)
testing.tRunner+0x22 /home/Checkouts/Mercurial/Go/src/pkg/testing/testing.go:132
testing.tRunner(0x2b1c522189c0, 0x2b1c52218360, 0x40161b, 0x2b1c522189c0)
goexit /home/Checkouts/Mercurial/Go/src/pkg/runtime/proc.c:145
goexit()

goroutine 1 [4]:
gosched+0x4e /home/Checkouts/Mercurial/Go/src/pkg/runtime/proc.c:542
gosched()
chanrecv+0x3e6 /home/Checkouts/Mercurial/Go/src/pkg/runtime/chan.c:330
chanrecv(0x2b1c52216b30, 0x2b1c52218a00, 0x2b1c00000010, 0xa0000000a, 0x8, ...)
runtime.chanrecv1+0x41 /home/Checkouts/Mercurial/Go/src/pkg/runtime/chan.c:432
runtime.chanrecv1(0x2b1c52216ae0, 0x2b1c521fa048)
testing.Main+0x241 /home/Checkouts/Mercurial/Go/src/pkg/testing/testing.go:159
testing.Main(0x2b1c52216ae0, 0x4bf7b8)
main.main+0x23 /home/Checkouts/Mercurial/Go/src/pkg/http/_testmain.go:30
main.main()
mainstart+0xf /home/Checkouts/Mercurial/Go/src/pkg/runtime/amd64/asm.s:60
mainstart()
goexit /home/Checkouts/Mercurial/Go/src/pkg/runtime/proc.c:145
goexit()
make[1]: *** [test] Error 2
make[1]: Leaving directory `/home/Checkouts/Mercurial/Go/src/pkg/http'
make: *** [http.test] Error 2

Issue 2:
by lee.hambley:

Steps to reproduce the problem:

If possible, include a link to a program on play.golang.org.

1. Use PostgreSQL
2. Use the lib/pq driver (latest, `78760269eebe5e70b28bb94bff676d7b28df275d
src/github.com/lib/pq (heads/master)`),
3. Use a table with a constraint
4. Violate that constraint when inserting using RETURNING. (i.e duplicate unique key)
5. Notice that when `sql.DB.QueryRow().Scan()` is used, `ErrNoRows` is returned before
errors are correctly checked for.

What is the expected output?

It is expected that `sql.QueryRow` will return a stub `*sql.Row` which will return an
error of type `*pq.Error` representing the constraint violation error. Typically
something like this https://github.com/lib/pq/blob/master/error.go#L157

What do you see instead?

`sql.QueryRow()` does not properly handle this case. It first checks for number of
returned rows (none, as we have failed to insert), and then returns `sql.ErrNoRows`
before checking if there is an error returned by the query.

Which compiler are you using (5g, 6g, 8g, gccgo)?

6g (standard Go code, no cgo as far as I am aware, `go build -x my/package` isn't
showing anything useful)

Which operating system are you using?

OSX 10.9 Mavericks 64bit

Which version are you using? (run 'go version')

go version go1.1.2 darwin/amd64

Please provide any additional information below.

There is an extensive Github thread (closed)
[here](lib/pq#77, discussing first, a similar issue, and then
re-opened with my findings at [this
comment](lib/pq#77 (comment). Specifically
someone has identified a possible weakness in the error checking of `func (rs *Rows)
Next() bool`, where `rs.lasterr` is only checked against `io.EOF` before being
overwritten and returned as `nil`.

The attached file isn't a complete running piece of software, but it is an extracted
sample, the same that is found in the GitHub thread.

Attachments:

known_issues_test.go (1191 bytes)