panic: segmentation violation during concurrent SELECTs

Question

panic: segmentation violation during concurrent SELECTs

raichu opened this issue 11 years ago · comments

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 · Answer 1 · Mon Apr 01 2013 01:21:49 GMT+0800 (China Standard Time)

What is your OS, CPU ?

raichu · Answer 2 · Mon Apr 01 2013 09:50:33 GMT+0800 (China Standard Time)

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

Josh Carter · Answer 3 · Wed Apr 24 2013 06:46:40 GMT+0800 (China Standard Time)

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 · Answer 4 · Wed Apr 24 2013 08:25:31 GMT+0800 (China Standard Time)

Could you please write code reproducable?

Mark von Minden · Answer 5 · Thu Apr 25 2013 00:25:34 GMT+0800 (China Standard Time)

@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 · Answer 6 · Wed Mar 19 2014 12:28:18 GMT+0800 (China Standard Time)

Hmm, I can't reproduce it.

mattn · Answer 7 · Fri Nov 14 2014 18:52:05 GMT+0800 (China Standard Time)

Do you still have this problem_

Mark von Minden · Answer 8 · Fri Nov 14 2014 22:40:43 GMT+0800 (China Standard Time)

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 notifications@github.com wrote:

Do you still have this problem_

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