runtime: access violation during cgo call in github.com/mattn/go-sqlite3 on windows 7 64-bit #9356

azdagron · 2014-12-16T22:39:44Z

OS: Windows 7 64-bit
GCC version: gcc (x86_64-posix-seh-rev1, Built by MinGW-W64 project) 4.9.1
Go version: 1.4 (but also happens on 1.2+, didn't check < 1.2)

Description:
when the below program is compiled and run, the go program either panics or crashes outright.

We did some spelunking and from what we can tell, the crash happens when sqlite3 tries to call a kernel32.dll function from its aSyscall array. The function pointer is supposed to point to an import jump table, but instead points to a page close to the jump table that has some garbage in it. Sampling other function pointers in the aSyscall array show they properly go the the import jump table.

We've used github.com/mattn/go-sqlite3 for quite a while with no issues. We made some unrelated changes and recompiled our application and suddenly hit the issue. Recompiling the program without the changes stopped triggering the bug, but once we found the issue we've been able to hit it with smaller programs (see the program below)

We suspect a linker issue, which is why we reported it here.

Repro instructions:

go get github.com/mattn/go-sqlite3
compile the following go program:

package main

import (
    "database/sql"
    "fmt"

    _ "github.com/mattn/go-sqlite3"
)

func main() {
    db, err := sql.Open("sqlite3", "foo.db")
    if err != nil {
        fmt.Printf("unable to open: %s", err)
        return
    }
    rows, err := db.Query(".tables;")
    if err == nil {
        rows.Close()
    }
    db.Close()
}

An example of the output:

Exception 0xc0000005 0x8 0x646138 0x646138
PC=0x646138
signal arrived during cgo execution

github.com/mattn/go-sqlite3._Cfunc_sqlite3_close_v2(0x8966b8, 0xc000000000)
        github.com/mattn/go-sqlite3/_obj/_cgo_gotypes.go:182 +0x4a
github.com/mattn/go-sqlite3.(*SQLiteConn).Close(0xc08204a018, 0x0, 0x0)
        c:/work/repro/src/github.com/mattn/go-sqlite3/sqlite3.go:320 +0x44
database/sql.(*driverConn).finalClose(0xc08200e1e0, 0x0, 0x0)
        c:/go/src/database/sql/sql.go:322 +0x125
database/sql.finalCloser.(database/sql.finalClose)┬╖fm(0x0, 0x0)
        c:/go/src/database/sql/sql.go:410 +0x52
database/sql.(*DB).Close(0xc082032000, 0x0, 0x0)
        c:/go/src/database/sql/sql.go:493 +0x3c2
main.main()
        c:/work/repro/src/repro/main.go:15 +0xdd

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
        c:/go/src/runtime/asm_amd64.s:2232 +0x1
rax     0x0
rbx     0x3
rcx     0x78
rdx     0x0
rdi     0x896ba8
rsi     0x897560
rbp     0x896970
rsp     0x22fce8
r8      0x5db0c0
r9      0x896ba8
r10     0x18
r11     0x5754e0
r12     0x0
r13     0x0
r14     0x0
r15     0x0
rip     0x646138
rflags  0x10206
cs      0x33
fs      0x53
gs      0x2b

The text was updated successfully, but these errors were encountered:

davecheney · 2014-12-16T22:42:40Z

Your repro does not check for a possible error on Open
On 17 Dec 2014 09:39, "azdagron" notifications@github.com wrote:

OS: Windows 7 64-bit
GCC version: gcc (x86_64-posix-seh-rev1, Built by MinGW-W64 project) 4.9.1
Go version: 1.4 (but also happens on 1.2+, didn't check < 1.2)

Description:
when the below program is compiled and run, the go program either panics
or crashes outright.

We did some spelunking and from what we can tell, the crash happens when
sqlite3 tries to call a kernel32.dll function from its aSyscall array. The
function pointer is supposed to point to an import jump table, but instead
points to a page close to the jump table that has some garbage in it.
Sampling other function pointers in the aSyscall array show they properly
go the the import jump table.

We've used github.com/mattn/go-sqlite3 for quite a while with no issues.
We made some unrelated changes and recompiled our application and suddenly
hit the issue. Recompiling the program without the changes stopped
triggering the bug, but once we found the issue we've been able to hit it
with smaller programs (see the program below)

We suspect a linker issue, which is why we reported it here.

Repro instructions:

go get github.com/mattn/go-sqlite3

compile the following go program:

package main

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

func main() {
db, err := sql.Open("sqlite3", "foo.db")
rows, err := db.Query(".tables;")
if err == nil {
rows.Close()
}
db.Close()
}

An example of the output:

Exception 0xc0000005 0x8 0x646138 0x646138
PC=0x646138
signal arrived during cgo execution
github.com/mattn/go-sqlite3._Cfunc_sqlite3_close_v2(0x8966b8, 0xc000000000)
github.com/mattn/go-sqlite3/_obj/_cgo_gotypes.go:182 +0x4agit.luolix.top/mattn/go-sqlite3.(_SQLiteConn).Close(0xc08204a018, 0x0, 0x0)
c:/work/repro/src/github.com/mattn/go-sqlite3/sqlite3.go:320 +0x44
database/sql.(_driverConn).finalClose(0xc08200e1e0, 0x0, 0x0)
c:/go/src/database/sql/sql.go:322 +0x125
database/sql.finalCloser.(database/sql.finalClose)┬╖fm(0x0, 0x0)
c:/go/src/database/sql/sql.go:410 +0x52
database/sql.(*DB).Close(0xc082032000, 0x0, 0x0)
c:/go/src/database/sql/sql.go:493 +0x3c2
main.main()
c:/work/repro/src/repro/main.go:15 +0xdd

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
c:/go/src/runtime/asm_amd64.s:2232 +0x1
rax 0x0
rbx 0x3
rcx 0x78
rdx 0x0
rdi 0x896ba8
rsi 0x897560
rbp 0x896970
rsp 0x22fce8
r8 0x5db0c0
r9 0x896ba8
r10 0x18
r11 0x5754e0
r12 0x0
r13 0x0
r14 0x0
r15 0x0
rip 0x646138
rflags 0x10206
cs 0x33
fs 0x53
gs 0x2b

—
Reply to this email directly or view it on GitHub
#9356.

azdagron · 2014-12-16T23:15:44Z

You are right. The original repro did check the error and it was nil. I removed all the printf goo i had in there right before submitting the report. As you can see from the stack trace, Close() is being called on a valid pointer.

I will update the repro instructions.

mattn · 2014-12-17T06:56:04Z

It's not reproduced on windows 32bit OS at least.

azdagron · 2014-12-17T16:45:54Z

I have some more information. I rolled back the version of github.com/mattn/go-sqlite3 to a previous version where the only thing that changed is the amalgamated sqlite3 code. The stars aligned such that the bug was not hit. I instrumented the code in sqlite3 so i could dump the aSyscall array and observe the function pointers it was using for the different kernel32 functions.

When everything is working, every function pointer in the aSyscall array properly points to the import thunks for the kernel32 functions:

aSyscall[0]: current=0000000000642FF0 default=0000000000000000 name=AreFileApisANSI
aSyscall[1]: current=0000000000000000 default=0000000000000000 name=CharLowerW
aSyscall[2]: current=0000000000000000 default=0000000000000000 name=CharUpperW
aSyscall[3]: current=0000000000642FF8 default=0000000000000000 name=CloseHandle
aSyscall[4]: current=0000000000643000 default=0000000000000000 name=CreateFileA
aSyscall[5]: current=0000000000643008 default=0000000000000000 name=CreateFileW
aSyscall[6]: current=0000000000643010 default=0000000000000000 name=CreateFileMappingA
aSyscall[7]: current=0000000000643018 default=0000000000000000 name=CreateFileMappingW
aSyscall[8]: current=0000000000643020 default=0000000000000000 name=CreateMutexW
aSyscall[9]: current=0000000000643028 default=0000000000000000 name=DeleteFileA
aSyscall[10]: current=0000000000643030 default=0000000000000000 name=DeleteFileW
aSyscall[11]: current=0000000000000000 default=0000000000000000 name=FileTimeToLocalFileTime
aSyscall[12]: current=0000000000000000 default=0000000000000000 name=FileTimeToSystemTime
aSyscall[13]: current=0000000000643038 default=0000000000000000 name=FlushFileBuffers
aSyscall[14]: current=0000000000643040 default=0000000000000000 name=FormatMessageA
aSyscall[15]: current=0000000000643048 default=0000000000000000 name=FormatMessageW
.... and so on

The dissassembly for the import thunks:

00000000`00642ff0 ff242580416400  jmp     qword ptr [a_out!crosscall2+0x2094a0 (00000000`00644180)]
00000000`00642ff7 90              nop
00000000`00642ff8 ff242588416400  jmp     qword ptr [a_out!crosscall2+0x2094a8 (00000000`00644188)]
00000000`00642fff 90              nop
00000000`00643000 ff242590416400  jmp     qword ptr [a_out!crosscall2+0x2094b0 (00000000`00644190)]
00000000`00643007 90              nop
00000000`00643008 ff2425a8416400  jmp     qword ptr [a_out!crosscall2+0x2094c8 (00000000`006441a8)]
00000000`0064300f 90              nop
00000000`00643010 ff242598416400  jmp     qword ptr [a_out!crosscall2+0x2094b8 (00000000`00644198)]
00000000`00643017 90              nop
00000000`00643018 ff2425a0416400  jmp     qword ptr [a_out!crosscall2+0x2094c0 (00000000`006441a0)]
00000000`0064301f 90              nop
00000000`00643020 ff2425b0416400  jmp     qword ptr [a_out!crosscall2+0x2094d0 (00000000`006441b0)]
00000000`00643027 90              nop
00000000`00643028 ff2425b8416400  jmp     qword ptr [a_out!crosscall2+0x2094d8 (00000000`006441b8)]
00000000`0064302f 90              nop
00000000`00643030 ff2425c0416400  jmp     qword ptr [a_out!crosscall2+0x2094e0 (00000000`006441c0)]
00000000`00643037 90              nop
00000000`00643038 ff2425c8416400  jmp     qword ptr [a_out!crosscall2+0x2094e8 (00000000`006441c8)]
00000000`0064303f 90              nop
00000000`00643040 ff2425d0416400  jmp     qword ptr [a_out!crosscall2+0x2094f0 (00000000`006441d0)]
00000000`00643047 90              nop
00000000`00643048 ff2425d8416400  jmp     qword ptr [a_out!crosscall2+0x2094f8 (00000000`006441d8)]

Then, i changed the repro code to add a cgo function that uses a few kernel32 functions. The cgo function is not called by repro code. Just having it there causes the function pointer in the aSyscall table for that function to not be an address to an import thunk, but rather the address to the Import Address Table entry for the function.

New repro code:

package main

/*
#cgo CFLAGS: -DWIN32_LEAN_AND_MEAN
#include <windows.h>

void Blah() {
    GetLastError();
    CreateMutexW(NULL, FALSE, NULL);
    FlushFileBuffers(NULL);
}
*/
import "C"

import (
    "database/sql"
    "fmt"

    _ "github.com/mattn/go-sqlite3"
)

func main() {
    db, err := sql.Open("sqlite3", "foo.db")
    if err != nil {
        fmt.Printf("unable to open: %s", err)
        return
    }
    _, err = db.Exec("CREATE TABLE IF NOT EXISTS foo(id INTEGER PRIMARY KEY)")
    fmt.Println("exec:", err)
    db.Close()
    fmt.Println("done.")
}

aSyscall dump of broken version:

aSyscall[0]: current=0000000000642FF0 default=0000000000000000 name=AreFileApisANSI
aSyscall[1]: current=0000000000000000 default=0000000000000000 name=CharLowerW
aSyscall[2]: current=0000000000000000 default=0000000000000000 name=CharUpperW
aSyscall[3]: current=0000000000644050 default=0000000000000000 name=CloseHandle
aSyscall[4]: current=0000000000642FF8 default=0000000000000000 name=CreateFileA
aSyscall[5]: current=0000000000643000 default=0000000000000000 name=CreateFileW
aSyscall[6]: current=0000000000643008 default=0000000000000000 name=CreateFileMappingA
aSyscall[7]: current=0000000000643010 default=0000000000000000 name=CreateFileMappingW
aSyscall[8]: current=0000000000644058 default=0000000000000000 name=CreateMutexW
aSyscall[9]: current=0000000000643018 default=0000000000000000 name=DeleteFileA
aSyscall[10]: current=0000000000643020 default=0000000000000000 name=DeleteFileW
aSyscall[11]: current=0000000000000000 default=0000000000000000 name=FileTimeToLocalFileTime
aSyscall[12]: current=0000000000000000 default=0000000000000000 name=FileTimeToSystemTime
aSyscall[13]: current=0000000000644070 default=0000000000000000 name=FlushFileBuffers
aSyscall[14]: current=0000000000643028 default=0000000000000000 name=FormatMessageA
aSyscall[15]: current=0000000000643030 default=0000000000000000 name=FormatMessageW

and the import thunks:

00000000`00642ff0 ff242598416400  jmp     qword ptr [a_out!crosscall2+0x2094b8 (00000000`00644198)]
00000000`00642ff7 90              nop
00000000`00642ff8 ff2425a0416400  jmp     qword ptr [a_out!crosscall2+0x2094c0 (00000000`006441a0)]
00000000`00642fff 90              nop
00000000`00643000 ff2425b8416400  jmp     qword ptr [a_out!crosscall2+0x2094d8 (00000000`006441b8)]
00000000`00643007 90              nop
00000000`00643008 ff2425a8416400  jmp     qword ptr [a_out!crosscall2+0x2094c8 (00000000`006441a8)]
00000000`0064300f 90              nop
00000000`00643010 ff2425b0416400  jmp     qword ptr [a_out!crosscall2+0x2094d0 (00000000`006441b0)]
00000000`00643017 90              nop
00000000`00643018 ff2425c0416400  jmp     qword ptr [a_out!crosscall2+0x2094e0 (00000000`006441c0)]
00000000`0064301f 90              nop
00000000`00643020 ff2425c8416400  jmp     qword ptr [a_out!crosscall2+0x2094e8 (00000000`006441c8)]
00000000`00643027 90              nop
00000000`00643028 ff2425d0416400  jmp     qword ptr [a_out!crosscall2+0x2094f0 (00000000`006441d0)]
00000000`0064302f 90              nop
00000000`00643030 ff2425d8416400  jmp     qword ptr [a_out!crosscall2+0x2094f8 (00000000`006441d8)]
00000000`00643037 90              nop

In this instance, import thunks for CloseHandle, CreateMutexW, and FlushFileBuffers are not even generated. The aSyscall entries for these functions are set to the address of the Import Address Table entries for the functions.

For example, kernel32!CreateMutexW resides at 0000000077850880. The Import Address Table entry for the function is at 0000000000644058:

0:000> dps 00644050
00000000`00644050  00000000`77861950 kernel32!CloseHandle
00000000`00644058  00000000`77850880 kernel32!CreateMutexW
00000000`00644060  00000000`77985380 ntdll!RtlDeleteCriticalSection
00000000`00644068  00000000`779b2f80 ntdll!RtlEnterCriticalSection
00000000`00644070  00000000`778460e0 kernel32!FlushFileBuffers
...

The function pointer for CreateMutexW in the aSyscall array should be to an import thunk that looks something like the following:

00000000`00XXXXXX YYYYYYYYYYYYYYYY  jmp     qword ptr [a_out!00000000\`00644058]

Instead, the function pointer is 00000000`00644058, which is wrong. It should either set to an import thunk which jumps to the address stored in the IAT for kernel!CreateMutexW or the direct address to kernel32!CreateMutexW.

Long story short, when the function is called, the addresses in the IAT are executed as code, beginning at 00000000`00644058, which of course crashes.

Here is my function to dump the aSyscall table:

void sqlite3_dump_asyscall() {
  int i = 0;
  for (i = 0; i < sizeof(aSyscall) / sizeof(*aSyscall); ++i) {
    printf("aSyscall[%d]: current=%p default=%p name=%s\n",
        i, aSyscall[i].pCurrent, aSyscall[i].pDefault, aSyscall[i].zName);
  }
}

And i call it in the sqlite3.go init function:

func init() {
    sql.Register("sqlite3", &SQLiteDriver{})
    C.sqlite3_dump_asyscall()
}

mattn · 2014-12-19T05:04:40Z

Hmm, as far as i can see, changes of amalgamated code seems not effect to this issue.

mattn/go-sqlite3@d369cbb

alexbrainman · 2014-12-19T05:11:01Z

@mattn, I see differently.

beeda4c works, while d369cbb is broken. Just like @azdagron described.

I am using latest windows/amd64 Go tip and gcc 4.9.1.

Alex

mattn · 2014-12-19T05:34:34Z

i don't see changes in logic. the changes which may effect seems to be only function table.

mattn/go-sqlite3@d369cbb#diff-ccfdd787473b0eb7a494298ebdb3b35dL34

others are not change the behavior, i guess.

azdagron · 2014-12-19T05:40:54Z

I'm not fully certain, but I'm pretty sure it isn't sqlite's fault, other than it happens to trigger the bug somewhere in the toolchain. If I "go install" github.com/mattn/go-sqlite3 on ref beeda4c, everything works fine, but if I add some cgo calls into other kernel32 functions in my code, then it breaks. Since the compiler already generated the code (i.e. go-sqlite.a) and the only thing changing is my code and then the linker putting it all into a PE file, I'm pretty sure it is something in the linker. Its as if it knows it should initialize the entry for the kernel32 function in the aSyscall array with an address to a generated import thunk (i.e. code that does a "jmp [X]"), but instead initializes it with X (i.e. the address into the IAT storing the real address of the kernel32 function).

I started digging into the various sections in the go-sqlite3.a, trying to find asyscall to see how it was getting statically initialized, but I haven't had the time to dig deeper.

mattn · 2014-12-19T06:42:20Z

Ah, I reproduced it just now on windows 32bit OS.

mattn · 2014-12-19T06:49:45Z

GitHub diff view seems strange. Below is a whole diff between previous and current.

https://gist.github.com/mattn/d54c9e77b4ffe05a851b

mattn · 2014-12-19T06:53:13Z

And seems go crashed at sqlite3BtreeLeave(). I'm thinking this is a bug of amalgamated code not go or driver. I'l check diff and will revert amalgamated code.

See golang/go#9356

mattn · 2014-12-19T07:33:51Z

Done mattn/go-sqlite3@4c5aec8

I don't mind you keep figure-out a cause of bug. :)

See golang/go#9356

alexbrainman · 2015-02-24T04:30:24Z

Please check this change https://go-review.googlesource.com/5711 to see if it fixes your problem.

Alex

mattn · 2015-02-24T05:43:23Z

I'll try this.

mattn · 2015-02-24T05:49:42Z

Seems not fixed.

Exception 0xc0000005 0x0 0xffffffff 0x6e70dd
PC=0x6e70dd
signal arrived during cgo execution

github.com/mattn/go-sqlite3._Cfunc_sqlite3_close_v2(0xa63a00, 0x0)
    github.com/mattn/go-sqlite3/_test/_obj_test/_cgo_gotypes.go:248 +0x3a
github.com/mattn/go-sqlite3.(*SQLiteConn).Close(0x118a4290, 0x0, 0x0)
    c:/dev/go/src/github.com/mattn/go-sqlite3/sqlite3.go:318 +0x34
database/sql.(*driverConn).finalClose(0x118863f0, 0x0, 0x0)
    C:/go/src/database/sql/sql.go:327 +0xda
database/sql.(finalCloser).(database/sql.finalClose)-fm(0x0, 0x0)
    C:/go/src/database/sql/sql.go:416 +0x40
database/sql.(*DB).Close(0x1188a1e0, 0x0, 0x0)
    C:/go/src/database/sql/sql.go:499 +0x2c4
github.com/mattn/go-sqlite3.TestCorruptDbErrors(0x1188a180)
    c:/dev/go/src/github.com/mattn/go-sqlite3/error_test.go:50 +0x572
testing.tRunner(0x1188a180, 0x6f9c6c)
    C:/go/src/testing/testing.go:448 +0xa0
created by testing.RunTests
    C:/go/src/testing/testing.go:556 +0x848

goroutine 1 [chan receive]:
testing.RunTests(0x666560, 0x6f9c60, 0x18, 0x18, 0x70fd01)
    C:/go/src/testing/testing.go:557 +0x87a
testing.(*M).Run(0x118862d0, 0x70fae0)
    C:/go/src/testing/testing.go:486 +0x6b
main.main()
    github.com/mattn/go-sqlite3/_test/_testmain.go:100 +0x177

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    c:/go/src/runtime/asm_386.s:2435 +0x1

goroutine 6 [runnable]:
database/sql.(*DB).connectionOpener(0x1188a1e0)
    C:/go/src/database/sql/sql.go:594
created by database/sql.Open
    C:/go/src/database/sql/sql.go:458 +0x271
eax     0x84
ebx     0x3
ecx     0x67615f
edx     0x0
edi     0xa63c88
esi     0xa645c8
ebp     0x12fdd8
esp     0x12fdbc
eip     0x6e70dd
eflags  0x10296
cs      0x1b
fs      0x3b
gs      0x0

alexbrainman · 2015-02-25T01:14:15Z

@mattn it works for me.

I applied my change with "git fetch https://go.googlesource.com/go refs/changes/11/5711/1 && git checkout FETCH_HEAD" command. Built Go.

I use gcc (GCC) 4.9.1.

I use beeda4c31194f4cdb15eb89d2f2b4be4474371c4 version of github.com/mattn/go-sqlite3.

I use this http://play.golang.org/p/8govbvHdB2 test program (as per #9356 (comment)).

This is what test program prints:

C:\go\path\src\issue9356>go run main.go
exec: <nil>
done.

But if I change to current Go tip (9b3ccc0). Same program prints:

C:\go\path\src\issue9356>go run main.go
Exception 0xc0000005 0x8 0x66d078 0x66d078
PC=0x66d078
signal arrived during cgo execution

github.com/mattn/go-sqlite3._Cfunc_sqlite3_exec(0x3761b8, 0x376ef0, 0x0, 0x0, 0x0, 0x0)
        github.com/mattn/go-sqlite3/_obj/_cgo_gotypes.go:374 +0x43
github.com/mattn/go-sqlite3.(*SQLiteConn).exec(0xc082020020, 0x5ed8b0, 0x36, 0x0, 0x0, 0x0, 0x0)
        c:/go/path/src/github.com/mattn/go-sqlite3/sqlite3.go:227 +0xc6
github.com/mattn/go-sqlite3.(*SQLiteConn).Exec(0xc082020020, 0x5ed8b0, 0x36, 0x6a4ab8, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        c:/go/path/src/github.com/mattn/go-sqlite3/sqlite3.go:166 +0x86
database/sql.(*DB).exec(0xc082050000, 0x5ed8b0, 0x36, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        c:/go/root/src/database/sql/sql.go:868 +0x2bd
database/sql.(*DB).Exec(0xc082050000, 0x5ed8b0, 0x36, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        c:/go/root/src/database/sql/sql.go:845 +0xc3
main.main()
        C:/go/path/src/issue9356/main.go:28 +0x19d

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
        c:/go/root/src/runtime/asm_amd64.s:2470 +0x1

goroutine 4 [runnable]:
database/sql.(*DB).connectionOpener(0xc082050000)
        c:/go/root/src/database/sql/sql.go:594
created by database/sql.Open
        c:/go/root/src/database/sql/sql.go:458 +0x33e
rax     0x0
rbx     0x22f63c
rcx     0x22f63c
rdi     0x22f640
rsi     0x22f638
rbp     0x22f63c
rsp     0x22f5b8
r8      0x76dd0000
r9      0x1b6
r10     0xc0000034
r11     0x8b0158
r12     0x22f638
r13     0x0
r14     0x3772a9
r15     0x22f6f4
rip     0x66d078
rflags  0x10206
cs      0x33
fs      0x53
gs      0x2b
exit status 2

(make sure you re-install github.com/mattn/go-sqlite3).

Please, provide instructions for me to reproduce what you see there. Thank you.

Alex

alexbrainman · 2015-02-25T02:21:39Z

@denji if you talking to me, I don't understand what you are saying.

Alex

mattn · 2015-02-25T02:34:45Z

@alexbrainman did you test with mattn/go-sqlite3@d369cbb ?

alexbrainman · 2015-02-25T02:52:15Z

I didn't test against mattn/go-sqlite3@d369cbb. Should I? I thought we had conversation about beeda4c31194f4cdb15eb89d2f2b4be4474371c4 all along. You don't expect me to debug / test every change of mattn/go-sqlite3. Do you? Perhaps you should see what has changed between these two version, and decide for yourself what to do.

mattn · 2015-02-25T03:08:10Z

As I said in above, I reverted the commit. This behavior doesn't be reproduced with older amalgamated code.

mattn/go-sqlite3@d369cbb is commit that be possible to reproduce on my environment.

alexbrainman · 2015-02-25T03:33:13Z

I tested mattn/go-sqlite3@d369cbb now. It works fine as I have described up above.

Alex

mattn · 2015-02-26T00:05:18Z

I could reproduce this on Win7 32bit

Exception 0xc0000005 0x0 0xffffffff 0x6cb0dd
PC=0x6cb0dd
signal arrived during cgo execution

github.com/mattn/go-sqlite3._Cfunc_sqlite3_close_v2(0x973a00, 0x0)
        github.com/mattn/go-sqlite3/_test/_obj_test/_cgo_gotypes.go:248 +0x3a
github.com/mattn/go-sqlite3.(*SQLiteConn).Close(0x117b4290, 0x0, 0x0)
        c:/dev/go/src/github.com/mattn/go-sqlite3/sqlite3.go:320 +0x34
database/sql.(*driverConn).finalClose(0x117963f0, 0x0, 0x0)
        c:/go/src/database/sql/sql.go:327 +0xda
database/sql.(finalCloser).(database/sql.finalClose)-fm(0x0, 0x0)
        c:/go/src/database/sql/sql.go:416 +0x40
database/sql.(*DB).Close(0x1179a1e0, 0x0, 0x0)
        c:/go/src/database/sql/sql.go:499 +0x2c4
github.com/mattn/go-sqlite3.TestCorruptDbErrors(0x1179a180)
        c:/dev/go/src/github.com/mattn/go-sqlite3/error_test.go:50 +0x572
testing.tRunner(0x1179a180, 0x6dda6c)
        c:/go/src/testing/testing.go:448 +0xa0
created by testing.RunTests
        c:/go/src/testing/testing.go:556 +0x848

goroutine 1 [chan receive]:
testing.RunTests(0x64cc3c, 0x6dda60, 0x16, 0x16, 0x6f3b01)
        c:/go/src/testing/testing.go:557 +0x87a
testing.(*M).Run(0x117962d0, 0x6f38e0)
        c:/go/src/testing/testing.go:486 +0x6b
main.main()
        github.com/mattn/go-sqlite3/_test/_testmain.go:96 +0x177

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
        c:/go/src/runtime/asm_386.s:2435 +0x1
eax     0x90
ebx     0x3
ecx     0x0
edx     0x0
edi     0x9745c8
esi     0x9745c8
ebp     0x12fdd8
esp     0x12fdbc
eip     0x6cb0dd
eflags  0x10286
cs      0x1b
fs      0x3b
gs      0x0
exit status 2
FAIL    github.com/mattn/go-sqlite3     0.960s

alexbrainman · 2015-02-26T05:10:54Z

Running http://play.golang.org/p/8govbvHdB2 against d369cbb does not crashes for me on windows-386 even without my change. I use gcc (GCC) 4.8.1 there.

Alex

denji · 2015-02-26T05:21:43Z

Here are the problems that I know of in GCC 4.8/4.9.x:
1.) https://kb.isc.org/article/AA-01167
2.) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56746 / http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525 / https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052

4.8+ CFLAGS=-ftrack-macro-expansion=0 -fno-builtin-memcmp
4.9+ CFLAGS=-fno-delete-null-pointer-checks

Can solve the problem or search dereferencing pointer in the code.

mattn · 2015-02-26T10:57:29Z

I'm using gcc 4.8.2, so added -ftrack-macro-expansion=0 -fno-builtin-memcmp into sqlite3_windows.go, but not solved unfortunatelly. 😢

azdagron · 2015-02-26T14:57:36Z

This changeset fixes the bug with my original repro configuration.

minux · 2015-03-24T05:37:39Z

Should be fixed by external linking support, #4069.

The test is a simple reproduction of issue 9356. Update #8948. Update #9356. Change-Id: Ia77bc36d12ed0c3c4a8b1214cade8be181c9ad55 Reviewed-on: https://go-review.googlesource.com/7618 Reviewed-by: Minux Ma <minux@golang.org>

gopherbot · 2015-04-25T20:13:12Z

CL https://golang.org/cl/5711 mentions this issue.

azdagron · 2015-11-06T17:51:38Z

So this didn't make it into Go1.5 and the CL references 1.6 but doesn't seem to have been merged. Anybody know the status of this?

ianlancetaylor · 2015-11-06T18:19:12Z

Somebody needs to review the CL or write a new one. Alex and I were unable to come to agreement on it.

alexbrainman · 2015-11-06T21:38:54Z

What @minux said. go1.5 uses external linker (mingw) to build cgo programs, so you should not see your problem now. The broken code in Go linker still remain, but it is not used any more. I hope it explains the situation.

Alex

ianlancetaylor changed the title ~~access violation during cgo call in github.com/mattn/go-sqlite3 on windows 7 64-bit~~ runtime: access violation during cgo call in github.com/mattn/go-sqlite3 on windows 7 64-bit Dec 16, 2014

ianlancetaylor added repo-main labels Dec 16, 2014

mattn added a commit to mattn/go-sqlite3 that referenced this issue Dec 19, 2014

Revert d369cbb

4c5aec8

See golang/go#9356

mattn added a commit to mattn/go-sqlite3 that referenced this issue Dec 31, 2014

Revert d369cbb

e068bcd

See golang/go#9356

alexbrainman mentioned this issue Feb 16, 2015

cgo: program crashes when more that one package uses cgo #8948

Closed

mattn mentioned this issue Feb 24, 2015

SQLite amalgamation to 3.8.9 mattn/go-sqlite3#171

Closed

mattn mentioned this issue Feb 26, 2015

error on execute example code mattn/go-sqlite3#163

Closed

minux closed this as completed Mar 24, 2015

mattn mentioned this issue Jun 26, 2015

Updated SQLite bindings to support SQLITE_ENABLE_UPDATE_DELETE_LIMIT flag mattn/go-sqlite3#215

Closed

mattn mentioned this issue Jul 31, 2015

Ship with SQLite 3.8.11 Bindings mattn/go-sqlite3#222

Closed

golang locked and limited conversation to collaborators Nov 10, 2016

gopherbot added the FrozenDueToAge label Nov 10, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

runtime: access violation during cgo call in github.com/mattn/go-sqlite3 on windows 7 64-bit #9356

runtime: access violation during cgo call in github.com/mattn/go-sqlite3 on windows 7 64-bit #9356

azdagron commented Dec 16, 2014

davecheney commented Dec 16, 2014

azdagron commented Dec 16, 2014

mattn commented Dec 17, 2014

azdagron commented Dec 17, 2014

mattn commented Dec 19, 2014

alexbrainman commented Dec 19, 2014

mattn commented Dec 19, 2014

azdagron commented Dec 19, 2014

mattn commented Dec 19, 2014

mattn commented Dec 19, 2014

mattn commented Dec 19, 2014

mattn commented Dec 19, 2014

alexbrainman commented Feb 24, 2015

mattn commented Feb 24, 2015

mattn commented Feb 24, 2015

alexbrainman commented Feb 25, 2015

alexbrainman commented Feb 25, 2015

mattn commented Feb 25, 2015

alexbrainman commented Feb 25, 2015

mattn commented Feb 25, 2015

alexbrainman commented Feb 25, 2015

mattn commented Feb 26, 2015

alexbrainman commented Feb 26, 2015

denji commented Feb 26, 2015

mattn commented Feb 26, 2015

azdagron commented Feb 26, 2015

minux commented Mar 24, 2015

gopherbot commented Apr 25, 2015

azdagron commented Nov 6, 2015

ianlancetaylor commented Nov 6, 2015

alexbrainman commented Nov 6, 2015

runtime: access violation during cgo call in github.com/mattn/go-sqlite3 on windows 7 64-bit #9356

runtime: access violation during cgo call in github.com/mattn/go-sqlite3 on windows 7 64-bit #9356

Comments

azdagron commented Dec 16, 2014

davecheney commented Dec 16, 2014

azdagron commented Dec 16, 2014

mattn commented Dec 17, 2014

azdagron commented Dec 17, 2014

mattn commented Dec 19, 2014

alexbrainman commented Dec 19, 2014

mattn commented Dec 19, 2014

azdagron commented Dec 19, 2014

mattn commented Dec 19, 2014

mattn commented Dec 19, 2014

mattn commented Dec 19, 2014

mattn commented Dec 19, 2014

alexbrainman commented Feb 24, 2015

mattn commented Feb 24, 2015

mattn commented Feb 24, 2015

alexbrainman commented Feb 25, 2015

alexbrainman commented Feb 25, 2015

mattn commented Feb 25, 2015

alexbrainman commented Feb 25, 2015

mattn commented Feb 25, 2015

alexbrainman commented Feb 25, 2015

mattn commented Feb 26, 2015

alexbrainman commented Feb 26, 2015

denji commented Feb 26, 2015

mattn commented Feb 26, 2015

azdagron commented Feb 26, 2015

minux commented Mar 24, 2015

gopherbot commented Apr 25, 2015

azdagron commented Nov 6, 2015

ianlancetaylor commented Nov 6, 2015

alexbrainman commented Nov 6, 2015