slice bounds out of range error on rows.Next() with go 1.5

[linuxerwang]

I got this stack trace with go 1.5:

panic: runtime error: slice bounds out of range [recovered]
panic: runtime error: slice bounds out of range

goroutine 75 [running]:
github.com/lib/pq.(_conn).errRecover(0x10ece000, 0x10e8de28)
/home/developer/go/src/github.com/lib/pq/error.go:482 +0x15c
github.com/lib/pq.(_rows).Next(0x10deb2c0, 0x10d991a0, 0xc, 0xc, 0x0, 0x0)
/home/developer/go/src/github.com/lib/pq/conn.go:1385 +0x6e0
database/sql.(*Rows).Next(0x10ede420, 0xe)
/usr/share/go-golang/src/database/sql/sql.go:1639 +0x134

The weird thing is that this error is not always raised. It happens randomly.

[johto]

Can you by any chance get a tcpdump of the unencrypted traffic between the server and the client when this happens? I've heard of a similar report (though on 1.4.2), but it's practically impossible to analyze these without having more information or a reproducible test case.

[linuxerwang]

I'll get a tcpdump later today when I get a chance.

Just found that when the program crashes because of the pq error, there are two cases. One is the above. The other is:

pq: unexpected Parse response 'D'
panic: runtime error: invalid memory address or nil pointer dereference
panic: runtime error: invalid memory address or nil pointer dereference

It's consistently reproducible: click the page first it loads correctly, click again 90% chance it fails.

[linuxerwang]

From the tcpdump, I found that when it succeeds the last packet has "cksum 0xfe28 (correct...)"; but when it fails the last packet has "cksum 0xfe28 (incorrect". So looks like that sometimes the last packet was missing.

[johto]

From the tcpdump, I found that when it succeeds the last packet has "cksum 0xfe28 (correct...)"; but when it fails the last packet has "cksum 0xfe28 (incorrect". So looks like that sometimes the last packet was missing.

That shouldn't cause this, unless sometimes a malformed packet slips through with a valid checksum.

[johto]

It's consistently reproducible: click the page first it loads correctly, click again 90% chance it fails.

Can you extract the relevant code into a test case which reproduces the problem?

[linuxerwang]

Can you extract the relevant code into a test case which reproduces the problem?

Created a github repository (https://github.com/linuxerwang/pq-issues-387) to hold the program and SQL script. The program is highly reduced from my original code, but sufficient to reveal the problem. The same program runs under go 1.4 without problem but consistently causes crash under go 1.5. I suspect it's related to PostgreSQL's array type.

Let me know what else I can help.
Thanks!

[cbandy]

I see two goroutines using one Tx concurrently.

[linuxerwang]

Is it not allowed? It worked without any issue under go 1.4.

[linuxerwang]

I see two goroutines using one Tx concurrently.

You are probably right. I found this old issue: #81

But it's still weird that the same program works fine under go 1.4 but not 1.5. Also, it works fine under go 1.5 if I am not using postgresql array type.

[hochhaus]

In go 1.4 were you running w/ GOMAXPROCS > 1?

[linuxerwang]

Ah, thanks, hochhaus! With GOMAXPROCS > 1 it also fails under go 1.4.
This issue should be closed.

[johto]

Is it not allowed? It worked without any issue under go 1.4.

It might've not failed under 1.4, but it was never allowed.