panic: segmentation violation during concurrent SELECTs

[raichu]

When GOMAXPROCS=1 eveything works out fine but with GOMAXPROCS=4 I'm getting

SIGSEGV: segmentation violation
PC=0x7fe715011f7d
signal arrived during cgo execution

github.com/mattn/go-sqlite3._Cfunc__sqlite3_open_v2(0x259def0, 0xc20055e378, 0x10006, 0x0, 0xc1fffc3fa8, ...)
        github.com/mattn/go-sqlite3/_obj/_cgo_defun.c:80 +0x2f
github.com/mattn/go-sqlite3.(*SQLiteDriver).Open(0xc70a80, 0xc200192320, 0x9, 0x0, 0x0, ...)
        github.com/mattn/go-sqlite3/_obj/sqlite3.cgo1.go:128 +0x1a2
database/sql.(*DB).conn(0xc2001aef50, 0xc20055e370, 0xffffffffffffffff, 0xc2004269f0)

...
goroutine 74 [syscall]:
github.com/mattn/go-sqlite3._Cfunc_sqlite3_step(0x7fe6a8000e48, 0xff00ffff)
        github.com/mattn/go-sqlite3/_obj/_cgo_defun.c:296 +0x2f
github.com/mattn/go-sqlite3.(*SQLiteRows).Next(0xc200480540, 0xc20055f1a0, 0xd, 0xd, 0xd, ...)
        github.com/mattn/go-sqlite3/_obj/sqlite3.cgo1.go:323 +0x3a

...
goroutine 72 [syscall]:
github.com/mattn/go-sqlite3._Cfunc_sqlite3_prepare_v2(0x7fe6bc0008e8, 0x7fe6bc011ca0, 0x7fe6ffffffff, 0xc200677008, 0xc200677010, ...)
        github.com/mattn/go-sqlite3/_obj/_cgo_defun.c:278 +0x2f
github.com/mattn/go-sqlite3.(*SQLiteConn).Prepare(0xc200677000, 0x86da50, 0xaf, 0x0, 0x0, ...)
        github.com/mattn/go-sqlite3/_obj/sqlite3.cgo1.go:174 +0xf5

...
goroutine 75 [syscall]:
github.com/mattn/go-sqlite3._Cfunc__sqlite3_open_v2(0x7fe6d4013ad0, 0xc20055e090, 0x7fe600010006, 0x0, 0x4, ...)
        github.com/mattn/go-sqlite3/_obj/_cgo_defun.c:80 +0x2f
github.com/mattn/go-sqlite3.(*SQLiteDriver).Open(0xc70a80, 0xc200192320, 0x9, 0x0, 0x0, ...)
        github.com/mattn/go-sqlite3/_obj/sqlite3.cgo1.go:128 +0x1a2

...
goroutine 71 [syscall]:
github.com/mattn/go-sqlite3._Cfunc_sqlite3_prepare_v2(0x7fe6ec0158c8, 0x7fe6ec0021f0, 0x7fe6ffffffff, 0xc20044bb28, 0xc20044bb30, ...)
        github.com/mattn/go-sqlite3/_obj/_cgo_defun.c:278 +0x2f
github.com/mattn/go-sqlite3.(*SQLiteConn).Prepare(0xc20044bb20, 0x85df90, 0x41, 0x0, 0x0, ...)
        github.com/mattn/go-sqlite3/_obj/sqlite3.cgo1.go:174 +0xf5

...
goroutine 81 [syscall]:
github.com/mattn/go-sqlite3._Cfunc_sqlite3_prepare_v2(0x7fe6d40008c8, 0x7fe6f00008c0, 0x7fe6ffffffff, 0xc20055e070, 0xc20055e078, ...)
        github.com/mattn/go-sqlite3/_obj/_cgo_defun.c:278 +0x2f
github.com/mattn/go-sqlite3.(*SQLiteConn).Prepare(0xc2006778a0, 0x86da50, 0xaf, 0x0, 0x0, ...)
        github.com/mattn/go-sqlite3/_obj/sqlite3.cgo1.go:174 +0xf5

...
goroutine 77 [syscall]:
github.com/mattn/go-sqlite3._Cfunc__sqlite3_open_v2(0x7fe6b00008c0, 0xc20055e558, 0x7fe600010006, 0x0, 0x4, ...)
        github.com/mattn/go-sqlite3/_obj/_cgo_defun.c:80 +0x2f
github.com/mattn/go-sqlite3.(*SQLiteDriver).Open(0xc70a80, 0xc200192320, 0x9, 0x0, 0x0, ...)
        github.com/mattn/go-sqlite3/_obj/sqlite3.cgo1.go:128 +0x1a2

...
goroutine 78 [syscall]:
github.com/mattn/go-sqlite3._Cfunc_sqlite3_close(0x7fe6d80008c8, 0x0)
        github.com/mattn/go-sqlite3/_obj/_cgo_defun.c:152 +0x2f
github.com/mattn/go-sqlite3.(*SQLiteConn).Close(0xc200677260, 0x7483e0, 0x4e68dd)
        github.com/mattn/go-sqlite3/_obj/sqlite3.cgo1.go:159 +0x7f

...
and so on

I'm basically running basic & simple SELECT queries, and scanning & closing rows.
Am I getting bitten by this? If yes, I'm wondering how should correct go programs be written: use locks for almost everything? use LockOSThread?

[mattn]

What is your OS, CPU ?

[raichu]

amd64 Linux, i5. sqlite version: 3.7.16. Using tip.

[joshcarter]

Seeing this problem as well, CentOS 6.3 x86_64 (kernel 2.6.32-279.19.1.el6.x86_64), SQLite 3.6.20 installed from yum, using Go tip. With heavy concurrent read load, I can trigger this almost instantly.

[mattn]

Could you please write code reproducable?

[mrkvm]

@mattn - I've been seeing this with @joshcarter on some code we've been working on. Here's a simple stress test that can reproduce the problem: https://gist.github.com/mrkvm/5453348

Given a high enough number of MAXGOPROCS and number of total queries, it hits the issue pretty quickly.

[mattn]

Hmm, I can't reproduce it.

[mattn]

Do you still have this problem_

[mrkvm]

Hi Matt,

I'm no longer working on the project that was using this code, so I can't
be sure. Sorry.

-mark

On Fri, Nov 14, 2014 at 3:52 AM, mattn [email protected] wrote:

Do you still have this problem_

—
Reply to this email directly or view it on GitHub
#51 (comment).