Issue 8948 in go: runtime: go build -race problem with sqlite3 on windows

[g...@googlecode.com]

Status: New
Owner: ----
CC: dvyu...@google.com
Labels: OS-Windows RaceDetector Repo-Main

New issue 8948 by alex.bra...@gmail.com: runtime: go build -race problem
with sqlite3 on windows
https://code.google.com/p/go/issues/detail?id=8948

Build this program:

package main

import (
"database/sql"
"fmt"
_ "github.com/mattn/go-sqlite3"
)

func main() {
db, err := sql.Open("sqlite3", "./test.db")
if err != nil {
fmt.Println("err%+v", err)
return
}
defer db.Close()

err = db.Ping()
if err != nil {
panic(err.Error())
}
fmt.Println("ok")
}

with "go build -race ..." command on windows, and run the program. Here is
the output:

C:\go\path\src\t>foo.exe
Exception 0xc0000005 0x8 0x6c3180 0x6c3180
PC=0x6c3180
signal arrived during cgo execution

github.com/mattn/go-sqlite3._Cfunc__sqlite3_open_v2(0x1337f70,
0xc08201fbd0, 0x10006, 0x0, 0x0)
github.com/mattn/go-sqlite3/_obj/_cgo_gotypes.go:102 +0x78
github.com/mattn/go-sqlite3.(*SQLiteDriver).Open(0xc082004620, 0x5fead0,
0x9, 0x0, 0x0, 0x0, 0x0)
c:/go/path/src/github.com/mattn/go-sqlite3/sqlite3.go:264 +0x238
database/sql.(*DB).conn(0xc08204e000, 0x401217, 0x0, 0x0)
c:/go/root/src/database/sql/sql.go:659 +0x7df
database/sql.(*DB).Ping(0xc08204e000, 0x0, 0x0)
c:/go/root/src/database/sql/sql.go:457 +0x4f
main.main()
C:/go/path/src/t/foo.go:17 +0x230

goroutine 2 [runnable]:
runtime.forcegchelper()
c:/go/root/src/runtime/proc.go:90
runtime.goexit()
c:/go/root/src/runtime/proc.c:1651

goroutine 3 [runnable]:
runtime.bgsweep()
c:/go/root/src/runtime/mgc0.go:66
runtime.goexit()
c:/go/root/src/runtime/proc.c:1651

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
c:/go/root/src/runtime/proc.c:1651

goroutine 4 [runnable]:
runtime.runfinq()
c:/go/root/src/runtime/malloc.go:705
runtime.goexit()
c:/go/root/src/runtime/proc.c:1651

goroutine 5 [runnable]:
database/sql.(*DB).connectionOpener(0xc08204e000)
c:/go/root/src/database/sql/sql.go:583
created by database/sql.Open
c:/go/root/src/database/sql/sql.go:447 +0x41a
rax 0x0
rbx 0x7
rcx 0x6ce4c0
rdx 0x6ce4c0
rdi 0x6ce4f0
rsi 0x6d2ec0
rbp 0x6ce7c0
rsp 0x22fd48
r8 0x2
r9 0x84
r10 0x42
r11 0x1330158
r12 0xc08201faf0
r13 0x1084d60
r14 0xc082016000
r15 0xc082008100
rip 0x6c3180
rflags 0x10246
cs 0x33
fs 0x53
gs 0x2b

Perhaps the problem is in github.com/mattn/go-sqlite3, but it is worth
checking.

Alex

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[g...@googlecode.com]

Comment #1 on issue 8948 by alex.bra...@gmail.com: runtime: go build -race

problem with sqlite3 on windows
https://code.google.com/p/go/issues/detail?id=8948

Reported at
https://groups.google.com/d/topic/golang-nuts/_yka6Okq7tc/discussion

[g...@googlecode.com]

Updates:
Labels: Release-Go1.4

Comment #2 on issue 8948 by mi...@golang.org: runtime: go build -race

problem with sqlite3 on windows
https://code.google.com/p/go/issues/detail?id=8948

Perhaps the race detector shouldn't instrument the cgo wrapper code.

[g...@googlecode.com]

Comment #3 on issue 8948 by dvyu...@google.com: runtime: go build -race

problem with sqlite3 on windows
https://code.google.com/p/go/issues/detail?id=8948

The crash happens inside of C code in

func _Cfunc__sqlite3_open_v2(p0 *_Ctype_char, p1 **_Ctype_struct_sqlite3,
p2 _Ctype_int, p3 *_Ctype_char) (r1 _Ctype_int) {
_cgo_runtime_cgocall_errno(_cgo_edfc822ad612_Cfunc__sqlite3_open_v2,
uintptr(unsafe.Pointer(&p0)))
return
}

So I don't think that not instrumenting cgo wrapper code will help.

Race detector does not instrument C code, so it seems that the C code just
crashes.

What's at PC 0x6c3180? That PC seems to dereference a NULL pointer.

[g...@googlecode.com]

Comment #4 on issue 8948 by alex.bra...@gmail.com: runtime: go build -race

problem with sqlite3 on windows
https://code.google.com/p/go/issues/detail?id=8948

It is crashing in sqlite3_os_init from sqlite3.c trying to execute
osGetSystemInfo. I suspect address of real syscall is not setup properly
during -race. It works fine when no -race. It might be go linker or gcc
fault for all I know. I don't know enough about these things ...

Alex