5.18 gets glibc message about node-odbc HOT 9 CLOSED

Are you using db2?

from node-odbc.

Yes, on this old 32bit box, db2 9.7fp4.

from node-odbc.

It's an old box but it's completely up to date with Ubuntu Server 12.04.2.

from node-odbc.

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Information%20Management/page/DB2%20and%20DB2%20Connect%209.7%20for%20Linux%20-%20Supported%20Environments

from node-odbc.

I'm pretty sure the issue has to do with the Unicode support that I enabled by default in this release. Probably shouldn't have done that. If you want to try disabling it, you can remove the UNICODE flag from binding.gyp. (https://github.com/wankdanker/node-odbc/blob/master/binding.gyp#L13).

My best guess is that in certain circumstances where ODBC writes to a buffer like in SQLDriverConnect if it is writing out a UCS2 encoding string into a buffer that is smaller than required it overflows the buffer causing errors such as you see.

I found a way to reproduce it on my end, so I should be able to nail it down.

from node-odbc.

Just pushed v0.5.19. If you get a chance to try it out, let me know if it fixes this issue or if you find any other regressions.

Thanks,

Dan

from node-odbc.

yep, all good...

u da man

from node-odbc.

Awesome. Glad to hear it. Curious to hear if your numbers increase or decrease at this version. We are avoiding some string copying now. But, also we have the added overhead of Unicode processing (as the default is set). If your numbers seem to decrease at all, try removing UNICODE from binding.gyp and recompiling.

Thanks for the feedback!

from node-odbc.

I put 5.19 into "production" today on x64 db2 10.5. Millions of calls... no issues that I can see.

But if you want me to compare one of your benchmarks at 5.14 to 5.19, let me know which one. You have a lot. :-)

from node-odbc.