Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash when adding column #62

Open
JoopClaireIT opened this issue Oct 29, 2015 · 9 comments
Open

Crash when adding column #62

JoopClaireIT opened this issue Oct 29, 2015 · 9 comments

Comments

@JoopClaireIT
Copy link

screenshot 2015-10-29 at 16 55 34

Sorry, didn't manage to copy/paste the error in this case. Will try to debug and solve myself, then issue PR, but just so you know about it 😃.

@alexbrainman
Copy link
Owner

If you can provide me with a small program I can run myself, I will investigate. Otherwise it is hard to guess what the problem is.

Alex

@JoopClaireIT
Copy link
Author

I know, will have to narrow it down myself first...

@JoopClaireIT
Copy link
Author

It only happens with one specific column, it's not number of columns, I bet it's something with the column type. This is with an Intersystems Caché database (uses SQL abstracting over an OO system internally, and technically only using strings internally). The contents of the specific column is a string describing car types. The specific lines point to the Next() method, and there in the columns.go file to the return c.BaseColumn.Value(c.Buffer[:c.Len]) line. So maybe in some corner cases c.Len is not accurate?

@JoopClaireIT
Copy link
Author

Just logged it with a printf of len(c.Buffer) and c.Len just before the return, and in the loop it goes well most of the time, then produces len(c.Buffer) as 51 but c.Len as 60, which of course causes it to crash. Maybe there needs to be an additional bounds check here?

JoopClaireIT added a commit to JoopClaireIT/odbc that referenced this issue Oct 30, 2015
This fixes it for me locally. (First had the second part of the slice set to the size of the buffer, but of course that's completely senseless...)
@alexbrainman
Copy link
Owner

I agree it must be to do with the way ODBC driver reports your column types. Is it possible for me reproduce this bug here? What software do I need? What are the steps? This package has been mainly used with MS SQL Server, and I wouldn't be surprised if there is some missing logice for other databases.

Alex

@JoopClaireIT
Copy link
Author

The database is Intersystems Caché, it's a commercial one so not sure if you would be able to gain access to one. The ODBC driver is a free download though, and there seems to be a free full functioning one person trial without time limit or other limitations that would make debugging impossible... The exact bug happened with me only in a rare case but on that specific case always, not intermittently, so I think you should be able to trace the origin then...

@ariel17ml
Copy link

Hello @alexbrainman. I've faced same problem using this driver with Apache Hive (query with single string column), applied changes provided by @JoopClaireIT and now it works like expected. Is there any planned ETA for merging it into production?

Thank you and best regards.
Ariel Ríos.

@alexbrainman
Copy link
Owner

Is there any planned ETA for merging it into production?

I would like to understand what is the problem that this PR fixes first.

Can you provide a small program that demonstrates the problem? Run your program, show its output here, and explain to me why you think that your program output is wrong.

Can I run your program here, on my own computer? What do I need to run it?

Thank you.

Alex

@haynesherway
Copy link

I am having the same issue, specifically it seems with null dates coming from an IBM iSeries database. They don't report SQL_NULL_DATA as true, so it doesn't get caught with the IsNull(). Then it panics when this slice is out of range. I spent way too much of my life investigating this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants