Panic after batch executing a number of statements about odbc HOT 6 CLOSED

> ... So far I haven't found a way to reliably reproduce this problem.

That is not good. It looks like memory corruption - it could be happening 
anywhere: in your program, in odbc package, in Go stdlib or in Windows dlls. 
Reproducible example will make hunting it down easier.

> ... Since I have not much experience yet with cgo, 

Looking at your stack trace I don't see cgo is used here. Does your program use 
any other packages that use cgo?

> ... any suggestions or ideas on how to debug this is very much appreciated.

Like I said earlier, I suspect it is memory corruption. If I am correct, it is 
very difficult to find the problem because the crash is caused by either Go 
garbage collector or by Windows memory manager freeing / reallocating memory. 
That means it crashes long way after the bug being hit.

One obvious thing for you to try is to use "latest" Go version. You said, you 
are using "go version 1.1.2". As far as I remember, there were some 
database/sql fixes that could fix your problem. It is certainly worth a try.

Alex

Thanks for the reply. I wrongly assumed the driver used cgo, because of the 
cgocall.c in the stacktrace. There are no other packages that use cgo.

I've reduced the problem to this:
https://gist.github.com/jstemmer/6461407

Some observations so far:
- The more parameters I use in my named query, the quicker the panic triggers.
- The longer the string variable I use as the parameters, the quicker the panic 
triggers (after executing the statement about ~25 times on my machine).
- Calling runtime.GC() after each execute seems to solve it (at least in this 
case; it runs the code in the gist every time without a panic).
- Panic happens both when compiling on windows or crosscompiling from linux to 
windows.
- Tried with go tip (version devel +601c402eb321), doesn't seem to change 
anything except triggering the panic faster (after executing the statement ~15 
times).
- The same code runs fine with the mysql driver 
(github.com/go-sql-driver/mysql) on both windows and linux.

I've worked around this issue by not using the sql parameters at all. I created 
the entire sql statement as a single string, including escaping each of the 
values where necessary, and executing it with the db.Exec function. This works 
great for millions of inserts, which makes me believe the problem has something 
to do with the way the parameters are handled.

After trying a few different things, I've managed to prevent the panic from 
happening by supplying a nil for the last parameter of SQLBindParameter (in 
param.go:105) when dealing with string parameters. This is possible since the 
strings are null terminated. It seems to fix the problem at first when running 
the different tests, but when I try to use it in my main application I 
encounter other errors. For example "[Microsoft][ODBC SQL Server Driver][SQL 
Server]Conversion failed when converting date and/or time from character 
string", which is strange since this worked fine before. No more panics 
however, which is good.

Unfortunately I don't have much time to investigate further to try and fix 
these issues. I've found another go odbc driver at 
https://github.com/LukeMauldin/lodbc which runs fine without any significant 
problems.

> I've reduced the problem to this:
> https://gist.github.com/jstemmer/6461407

Thank you for that. I can see the problem know. Here is a fix 
https://codereview.appspot.com/13253046/ Please, review and let me know, if you 
like.

> Unfortunately I don't have much time to investigate further to try and fix 
these issues. I've found another go odbc driver at 
https://github.com/LukeMauldin/lodbc which runs fine without any significant 
problems.

Fair enough. Luckily all these drivers are interchangeable. It should just be a 
matter of changing import statement.

Alex

Thanks for the patch. Some more issues popped up after applying the patch, I 
tracked most of them down. I've added some comments at 
https://codereview.appspot.com/13253046/

This issue was closed by revision d64013ec9967.