Closed GoogleCodeExporter closed 9 years ago
> ... 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
Original comment by alex.bra...@gmail.com
on 6 Sep 2013 at 12:45
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.
Original comment by stemmert...@gmail.com
on 6 Sep 2013 at 9:30
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.
Original comment by stemmert...@gmail.com
on 8 Sep 2013 at 1:34
> 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
Original comment by alex.bra...@gmail.com
on 9 Sep 2013 at 2:18
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/
Original comment by stemmert...@gmail.com
on 9 Sep 2013 at 10:07
This issue was closed by revision d64013ec9967.
Original comment by alex.bra...@gmail.com
on 13 Sep 2013 at 2:09
Original issue reported on code.google.com by
stemmert...@gmail.com
on 5 Sep 2013 at 12:27