Menu
▾
▴
iodbc-bugs — discussion of bugs found in iODBC
You can subscribe to this list here.
| 2004 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
(10) |
Nov
(10) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
|
Feb
(2) |
Mar
(2) |
Apr
|
May
(1) |
Jun
(4) |
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
(1) |
| 2006 |
Jan
(3) |
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(2) |
| 2007 |
Jan
(2) |
Feb
(5) |
Mar
(2) |
Apr
(1) |
May
|
Jun
(3) |
Jul
|
Aug
(1) |
Sep
(2) |
Oct
(3) |
Nov
(3) |
Dec
(1) |
| 2008 |
Jan
(4) |
Feb
(7) |
Mar
|
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(9) |
Oct
(12) |
Nov
(24) |
Dec
(31) |
| 2009 |
Jan
(10) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2011 |
Jan
(1) |
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
(8) |
Apr
|
May
(4) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
(1) |
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2014 |
Jan
|
Feb
(1) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
|
From: Bo A. <boe...@ao...> - 2015-09-28 06:37:56
|
Patch: https://github.com/openlink/iODBC/pull/10 Bo -----Original Message----- From: Bo Anderson <boe...@ao...> To: iodbc-bugs <iod...@li...> Sent: Sun, 27 Sep 2015 21:58 Subject: Re: Invalid connection string causes malloc errors Interestingly, I do not get this issue if I build iODBC myself. It only seems to happen with the prebuilt framework from iodbc.org. Bo -----Original Message----- From: Bo Anderson <boe...@ao...> To: iodbc-bugs <iod...@li...> Sent: Sat, 5 Sep 2015 1:10 Subject: Invalid connection string causes malloc errors It seems that entering invalid connection causes iODBC to throw malloc errors. I haven't done an extensive test to see what version the problem started but it did work in 03.52.0709.0909 (the older version I had installed). Is this reproducible on your end? $ /Library/Application\ Support/iODBC/bin/iodbctest iODBC Demonstration program This program shows an interactive SQL processor Driver Manager: 03.52.1015.0210 Enter ODBC connect string (? shows list): = iodbctest(86869,0xa11bc1d4) malloc: *** error for object 0x20: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug iodbctest(86869,0xa11bc1d4) malloc: *** error for object 0x931e2827: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug 1: SQLDriverConnect = [iODBC][Driver Manager]Invalid attribute/option identifier (0) SQLSTATE=HY092 1: ODBC_Connect = [iODBC][Driver Manager]Invalid attribute/option identifier (0) SQLSTATE=HY092 Have a nice day. Bo |
|
From: Bo A. <boe...@ao...> - 2015-09-27 20:59:08
|
Interestingly, I do not get this issue if I build iODBC myself. It only seems to happen with the prebuilt framework from iodbc.org. Bo -----Original Message----- From: Bo Anderson <boe...@ao...> To: iodbc-bugs <iod...@li...> Sent: Sat, 5 Sep 2015 1:10 Subject: Invalid connection string causes malloc errors It seems that entering invalid connection causes iODBC to throw malloc errors. I haven't done an extensive test to see what version the problem started but it did work in 03.52.0709.0909 (the older version I had installed). Is this reproducible on your end? $ /Library/Application\ Support/iODBC/bin/iodbctest iODBC Demonstration program This program shows an interactive SQL processor Driver Manager: 03.52.1015.0210 Enter ODBC connect string (? shows list): = iodbctest(86869,0xa11bc1d4) malloc: *** error for object 0x20: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug iodbctest(86869,0xa11bc1d4) malloc: *** error for object 0x931e2827: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug 1: SQLDriverConnect = [iODBC][Driver Manager]Invalid attribute/option identifier (0) SQLSTATE=HY092 1: ODBC_Connect = [iODBC][Driver Manager]Invalid attribute/option identifier (0) SQLSTATE=HY092 Have a nice day. Bo |
|
From: Bo A. <boe...@ao...> - 2015-09-05 00:11:05
|
It seems that entering invalid connection causes iODBC to throw malloc errors. I haven't done an extensive test to see what version the problem started but it did work in 03.52.0709.0909 (the older version I had installed). Is this reproducible on your end?
$ /Library/Application\ Support/iODBC/bin/iodbctest
iODBC Demonstration program
This program shows an interactive SQL processor
Driver Manager: 03.52.1015.0210
Enter ODBC connect string (? shows list): =
iodbctest(86869,0xa11bc1d4) malloc: *** error for object 0x20: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
iodbctest(86869,0xa11bc1d4) malloc: *** error for object 0x931e2827: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
1: SQLDriverConnect = [iODBC][Driver Manager]Invalid attribute/option identifier (0) SQLSTATE=HY092
1: ODBC_Connect = [iODBC][Driver Manager]Invalid attribute/option identifier (0) SQLSTATE=HY092
Have a nice day.
Bo
|
|
From: Patrick v. K. <pk...@op...> - 2015-02-27 15:36:31
|
HI Son Nguyen,
>
> According to ODBC standard, pcbInfoValue of SQLGetinfoW() api returns the number of bytes for rgbInfoValue.
>
> Here is the current code in the .\iodbc\info.c file. The function returns the total number of characters instead, eg *pcbInfoValue is set to 10 for the value "03.52.0000"
>
> 798
> 799 if (pcbInfoValue != NULL)
> 800 {
> 801 *pcbInfoValue = (SWORD) len;
> 802 }
> 803
> 804 return retcode;
> 805 }
>
>
> The code lines above should be changed as following to return the total number of bytes instead.
>
> 798
> 799 if (pcbInfoValue != NULL)
> 800 {
> 801 *pcbInfoValue = (waMode != 'W' ? (SWORD) len : (SWORD) len * sizeof(wchar_t) ) ;
> 802 }
> 803
> 804 return retcode;
> 805 }
>
Thank you for making us aware of this issue.
One of our developers has created a more comprehensive patch for this as the code had some other issues.
You can find the latest version including a fix for your problem on github in the develop branch:
https://github.com/openlink/iODBC/
Patrick
|
|
From: Son N. <Son...@ca...> - 2015-02-24 15:23:57
|
Hi,
According to ODBC standard, pcbInfoValue of SQLGetinfoW() api returns the
number of bytes for rgbInfoValue.
Here is the current code in the .\iodbc\info.c file. The function returns
the total number of characters instead, eg *pcbInfoValue is set to 10 for
the value "03.52.0000"
798
799 if (pcbInfoValue != NULL)
800 {
801 *pcbInfoValue = (SWORD) len;
802 }
803
804 return retcode;
805 }
The code lines above should be changed as following to return the total
number of bytes instead.
798
799 if (pcbInfoValue != NULL)
800 {
801 *pcbInfoValue = (waMode != 'W' ? (SWORD) len : (SWORD) len *
sizeof(wchar_t) ) ;
802 }
803
804 return retcode;
805 }
Thanks
Son Nguyen
|
|
From: Ted T. Jr <tth...@op...> - 2014-03-24 18:29:22
|
On Mar 24, 2014, at 01:50 PM, Toralf Förster <tor...@gm...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > - -- > MfG/Sincerely > Toralf Förster Hello, Toralf — I’m sorry, but you must unsubscribe yourself, by using one of the links found in the headers of every list message — List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/iodbc-bugs>, <mailto:iod...@li...?subject=unsubscribe> Best regards, Ted -- A: Yes. http://www.guckes.net/faq/attribution.html | Q: Are you sure? | | A: Because it reverses the logical flow of conversation. | | | Q: Why is top posting frowned upon? Ted Thibodeau, Jr. // voice +1-781-273-0900 x32 Senior Support & Evangelism // mailto:tth...@op... // http://twitter.com/TallTed OpenLink Software, Inc. // http://www.openlinksw.com/ 10 Burlington Mall Road, Suite 265, Burlington MA 01803 Weblog -- http://www.openlinksw.com/blogs/ LinkedIn -- http://www.linkedin.com/company/openlink-software/ Twitter -- http://twitter.com/OpenLink Google+ -- http://plus.google.com/100570109519069333827/ Facebook -- http://www.facebook.com/OpenLinkSoftware Universal Data Access, Integration, and Management Technology Providers |
|
From: Toralf F. <tor...@gm...> - 2014-03-24 17:51:00
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 - -- MfG/Sincerely Toralf Förster pgp finger print:1A37 6F99 4A9D 026F 13E2 4DCF C4EA CDDE 0076 E94E -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMwcHsACgkQxOrN3gB26U5eJQEAjiDyCPjy8Vm+wm2Oq/Lk4eVH oiSeNz6mR90ToVeAh6gA/i8zaIs9CWfaOtug0Mbt1+NVobyynVI67UAKeGKxSmXy =8lo/ -----END PGP SIGNATURE----- |
|
From: James D. <ja...@si...> - 2014-03-21 22:10:39
|
Hi, I ran into a bug with the SQLInstallDriverEx function. It doesn't accept paths to driver library files that the caller does not have write permission for. Some drivers ship with only read-only permissions. The problem is in SQLINstallDriverEx.c at line 232. The line if (lpszPathIn && access (lpszPathIn, R_OK | W_OK | X_OK)) fails because the W_OK bit is set. Thanks, James |
|
From: Bogdan D. <bog...@or...> - 2014-02-07 07:23:07
|
Hi,
I found a problem with SQLCancel() function in iODBC.
Normally SQLCancel() is called upon an active statement from a separate
client app thread to break the execution of a long running statement.
However, the current implementation (3.52.8) of SQLCancel() does not
allow that.
Here is the fragment from hstmt.c (lines 1135-1145):
SQLRETURN SQL_API
SQLCancel (SQLHSTMT hstmt)
{
ENTER_STMT (hstmt,
trace_SQLCancel (TRACE_ENTER, hstmt));
retcode = SQLCancel_Internal (hstmt);
LEAVE_STMT (hstmt,
trace_SQLCancel (TRACE_LEAVE, hstmt));
}
The ENTER_STMT macro checks for stmt_cip (if the call is in progress for
this handle) and returns the error [S1010] "Function sequence error".
For instance, MySQL ODBC driver does not use the same particular hstmt.
It only gets the connection ID and opens a new connection (SQLHDBC) and
a new statement (SQLHSTMT) handles to kill the running query.
There are a few ways to deal with the problem, but I think that the
easiest one would be introducing another macro like ENTER_STMT_ASYNC,
which would take into account the asynchronous nature of SQLCancel() calls.
Please let me know if you have any questions.
Thanks.
--
Best Regards,
Bogdan Degtyariov
Senior Developer
MySQL/Sun/Oracle
Melbourne, Australia
|
|
From: Luiz C. R. <lra...@ya...> - 2013-12-27 02:12:49
|
Hello,
I've made this patch some time ago and it become "lost" in the HD. These
days, as I found it again, it seemed to be a good time to submit it back
to the community.
--- patch begin -------------------------------
--- a/libiodbc-3.52.7/iodbc/connect.c 2009-09-10 10:04:55.000000000
-0300
+++ b/libiodbc-3.52.7/build/connect.c 2013-05-28 20:17:46.061968000
-0300
@@ -1006,6 +1006,7 @@ _iodbcdm_driverload (
char *path = drv;
char cp_probe[1024] = {""};
int cp_timeout = 0;
+ void *pfaux;
if (drv == NULL || ((char*)drv)[0] == '\0')
{
@@ -1184,7 +1185,8 @@ _iodbcdm_driverload (
/*
* If the driver is Unicode
*/
- if ( _iodbcdm_getproc (pdbc, en_ConnectW))
+ pfaux = _iodbcdm_getproc (pdbc, en_ConnectW);
+ if ((pfaux) && (pfaux != (void *)SQLConnectW))
penv->unicode_driver = 1;
/* call driver's SQLAllocHandle() or SQLAllocEnv() */
--- patch end -------------------------------
Let me picture what it is supposed to do, although I don't remember the
details as deeply as in the time it was written.
The environment is a Slackware Linux 14.0, with iodbc 3.52.7 - but it
happens also with the latest 3.52.8. The library doesn't verify
correctly if the
driver is Unicode or ANSI. In my case, I used an ANSI driver, but
sometimes the library concluded it was a Unicode one and this leads to
errors later on.
The problem is that the library tries to search for the symbol
SQLConnectW,
supposed to be in the driver and make a statement about ANSI or Unicode
based on the result. If SQLConnectW is present, there should be an
Unicode driver. When it's the case of an ANSI driver, SQLConnectW symbol
shouldn't be there. However, if you'd check the code of iodbc/connect.c
(more
specifically at line 2234 in the version 3.52.7), there is a SQLConnectW
function. The function _iodbcdm_getproc() in that environment (not sure
about other - BSD, Mac OS X, other *nix) returns this symbol,address,
and the original library wrongly concludes it's Unicode.
The solution is to check the pointer returned by _iodbcdm_getproc()
additionally with the address of the internal SQLConnectW(), and not
simply
checking the return value with null. If the return is null OR if it
matches the internal SQLConnectW, the newer version conclude the driver
is ANSI.
Otherwise (that is, if the return is not null and doesn't match
SQLConnectW), it is Unicode.
Hope it can help,
Luiz Ramos
São Paulo - Brazil
lramos dot prof at yahoo dot com dot br
|
|
From: Ted T. Jr <tth...@op...> - 2013-07-31 21:08:19
|
Hi, Maury -- On Jul 31, 2013, at 02:52 PM, Maury Markowitz wrote: > I no longer recall when I installed this, but some time ago (a year?) I installed a Safari plugin that allowed me to perform iODBC queries within a web page. I had forgot I had it installed, and can no longer find anything about it anywhere. > > Anyhoo, recently the Wikipedia has installed a new editor system, VE. When this plugin was turned on, it inserted data into the resulting article text... > > <embed type="application/iodbc" width="0" height="0" /> > > This is, of course, not a good thing. > > Can anyone help get me pointed on the right path to getting this fixed? The wiki developers refuse to admit any fault. The issue you're hitting isn't due to any bug in iODBC, so this should probably leave the iODBC-bugs list after this post. You've probably installed the OpenLink HTML5 WebDB-to-ODBC Bridge, and associated ODBC Bridge Internet Plug-in (for Safari). It uses iODBC on platforms like Mac OS X, where that is the local ODBC Driver Manager. <http://wikis.openlinksw.com/UdaWikiWeb/InstallConfigODBCHTML5Bridge> You did not indicate which version of Mac OS X you're on, so here are a couple links that may be useful if you decide to remove the plug-ins due to this issue -- Lion (10.7.x) -- <http://support.apple.com/kb/PH5063> Mountain Lion (10.8.x) -- <http://support.apple.com/kb/PH11931> The process is similar for older versions of Mac OS X. If you continue to have difficulties with this, please visit the public OpenLink Discussion Forums -- <http://boards.openlinksw.com/support/index.php> -- or log a free and confidential Support Case -- <http://support.openlinksw.com/support/online-support.vsp> Best regards, Ted OpenLink Support -- A: Yes. http://www.guckes.net/faq/attribution.html | Q: Are you sure? | | A: Because it reverses the logical flow of conversation. | | | Q: Why is top posting frowned upon? Ted Thibodeau, Jr. // voice +1-781-273-0900 x32 Senior Support & Evangelism // mailto:tth...@op... // http://twitter.com/TallTed OpenLink Software, Inc. // http://www.openlinksw.com/ 10 Burlington Mall Road, Suite 265, Burlington MA 01803 Weblog -- http://www.openlinksw.com/blogs/ LinkedIn -- http://www.linkedin.com/company/openlink-software/ Twitter -- http://twitter.com/OpenLink Google+ -- http://plus.google.com/100570109519069333827/ Facebook -- http://www.facebook.com/OpenLinkSoftware Universal Data Access, Integration, and Management Technology Providers |
|
From: Maury M. <mau...@gm...> - 2013-07-31 18:52:36
|
I no longer recall when I installed this, but some time ago (a year?) I installed a Safari plugin that allowed me to perform iODBC queries within a web page. I had forgot I had it installed, and can no longer find anything about it anywhere. Anyhoo, recently the Wikipedia has installed a new editor system, VE. When this plugin was turned on, it inserted data into the resulting article text... <embed type="application/iodbc" width="0" height="0" /> This is, of course, not a good thing. Can anyone help get me pointed on the right path to getting this fixed? The wiki developers refuse to admit any fault. |
|
From: Toralf F. <tor...@gm...> - 2012-12-07 20:54:25
|
Hello,
at an stable grentoo Linux I got this QA warning, which I'd like to
forward to you (gcc-4.6.3)
QA: other
QA Notice: Package triggers severe warnings which indicate that it
may exhibit random runtime failures.
administrator.c:159:4: warning: implicit declaration of function
‘dladdr’ [-Wimplicit-function-declaration]
confirm.c:263:3: warning: implicit declaration of function
‘create_message’ [-Wimplicit-function-declaration]
Please do not file a Gentoo bug and instead report the above QA
issues directly to the upstream developers of this software.
Homepage: http://www.iodbc.org/
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
|
|
From: Anatolii S. <sa...@gm...> - 2012-10-19 07:04:34
|
Hi there! Please accept the attached patch, it fixes an infinite loop. Anatolii Sakhnik |
|
From: Daniel R. G. <os...@te...> - 2012-09-06 19:21:50
|
On Sat, 25 Aug 2012, Brad Smith wrote: > The diff below fixes the pkg-config file by substituting -ldl for > LIBADD_DL since some OS's do not have a libdl and adds the missing > libpthread for Libs.private to fix the static linking. For iodbc-config > the missing libpthread is added for the static linking scenario. I agree with substituting @LIBADD_DL@ for -ldl in libiodbc.pc.in; that was clearly an oversight. However, "-lpthread" doesn't necessarily belong in these two files. For one, the library could be named -lpthreads (plural), or the pthreads functions may already be in the C library (so no additional library is needed). For two, iODBC can be built without threading support using --disable-pthreads. Have a look at the "Checkout pthread situation" section in configure.ac. -lpthread may be needed in some static-linking scenarios, but that's not the only permutation that needs to be covered. --Daniel -- Daniel Richard G. || da...@te... || Software Developer Teragram Linguistic Technologies (a division of SAS) http://www.teragram.com/ |
|
From: Brad S. <br...@co...> - 2012-08-25 13:02:34
|
The diff below fixes the pkg-config file by substituting -ldl
for LIBADD_DL since some OS's do not have a libdl and adds
the missing libpthread for Libs.private to fix the static
linking. For iodbc-config the missing libpthread is added
for the static linking scenario.
diff --git a/admin/libiodbc.pc.in b/admin/libiodbc.pc.in
index d0eb4b4..e926ae0 100644
--- a/admin/libiodbc.pc.in
+++ b/admin/libiodbc.pc.in
@@ -88,5 +88,6 @@ Name: iODBC
Description: @PACKAGE_NAME@
Version: @PACKAGE_VERSION@
Requires:
-Libs: -L${libdir} -liodbc -liodbcinst -ldl
+Libs: -L${libdir} -liodbc -liodbcinst @LIBADD_DL@
+Libs.private: -lpthread
Cflags: -I${includedir}
diff --git a/bin/iodbc-config.in b/bin/iodbc-config.in
index e2aafef..4148c40 100644
--- a/bin/iodbc-config.in
+++ b/bin/iodbc-config.in
@@ -201,7 +201,7 @@ fi
if test "$echo_staticlibs" = "yes"; then
libs=""
if test "$lib_iodbc" = "yes"; then
- libs="@libdir@/libiodbc.a @libdir@/libiodbcinst.a @LIBADD_DL@"
+ libs="@libdir@/libiodbc.a @libdir@/libiodbcinst.a -lpthread @LIBADD_DL@"
fi
echo "$libs"
fi
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
|
|
From: Daniel R. G. <os...@te...> - 2012-07-25 20:21:50
|
The attached patch addresses a handful of minor issues in iODBC's use of
the GNU Autotools, mostly obsolete syntax and nits that the Autotools
themselves warn about. (These were spurred largely by the changes to
bootstrap.sh.)
A walk-through of the changes:
++ acinclude.m4
* Properly quote macro name in AC_DEFUN
* Use AC_LINK_IFELSE instead of the obsolete AC_TRY_LINK
++ admin/gtk-2.0.m4, admin/gtk.m4
* Properly quote macro name in AC_DEFUN
(These macros could use more work, but as they are third-party, and the
third party has not bothered to fix them, I've left out doing more here)
++ bootstrap.sh
* Call the various Autotools initialization programs with --warnings=all
where applicable, to help with QA (and autoconf also gets no-obsolete so
we don't hear about the obsolete usages still in the GTK m4 macros)
++ configure.in
* Use AC_CONFIG_HEADERS instead of the obsolete AM_CONFIG_HEADER
* Use AS_HELP_STRING instead of the obsolete AC_HELP_STRING
* Don't use A[CS]_HELP_STRING inside an echo "...", as this is not how the
macro is intended to be used, and it doesn't do much good anyway
* Use AM_PROG_CC_C_O because AC_PROG_CC_C_O is not sufficient
* Replaced the obsolete AC_LIBTOOL_DLOPEN and AM_PROG_LIBTOOL macros with
a call to LT_INIT
* Fixed the doc string for --disable-gui
* Use AC_RUN_IFELSE instead of the obsolete AC_TRY_RUN
* Can't use a variable in the doc string for --with-iodbc-filedsnpath, so
replaced "$inidir" with "INIDIR"
* Rewrote the config info summary at the end to use "cat <<EOF" instead of
a bunch of echo commands; this is more readable and makes getting the
tabs right a *lot* easier
++ drvproxy/Makefile.am, drvproxy/gtk/Makefile.am, iodbc/Makefile.am,
iodbc/trace/Makefile.am, iodbcadm/Makefile.am,
iodbcadm/gtk/Makefile.am, iodbcinst/Makefile.am, samples/Makefile.am
* Use AM_CPPFLAGS instead of the obsolete variable name INCLUDES
--Daniel
--
Daniel Richard G. || da...@te... || Software Developer
Teragram Linguistic Technologies (a division of SAS)
http://www.teragram.com/ |
|
From: s. <876...@qq...> - 2012-07-20 10:00:24
|
Hi, I use iodbc and libmyodbc to connect mysql5, that is ok.but when I wanted to create a table that had multibyte characters name, the sql was failed. I debugged it , and found that the sql statement was truncated by iodbc at the position where the multibyte character occurred. the statement is as below: CREATE TABLE TC1_中文 (c1_测试 int); Does iodbc support multibyte characters in sql? (UTF8 encoding) Thank you! Regards, |
|
From: Daniel R. G. <os...@te...> - 2012-07-18 20:55:03
|
Hello list,
I have a few fixes to contribute to iODBC. The attached patch is against
current git master source. A walk-through of the changes:
configure.in:
* Rewrote the "underscore before symbols" code snippet to eliminate
warnings (e.g. improper main() prototype) and potential optimizing-out
of the fnord() function
* Use ${CFLAGS} with ${CC}, as the former may contain important flags
* Fail if pthread.h is not found, otherwise the configuration falls into
a state where threading is enabled, but the header is missing
include/sqltypes.h:
* Need to check whether _MSC_VER is defined before using it in a cpp
conditional, otherwise -Wundef gives a warning
iodbc/dlproc.h:
* Simplified the conditional affecting the definition of HDLL. (Is there
any non-Win32 system that provides this type?)
(I was doing some test-building on an experimental system and got
bitten by this; it seemed to me that rather than whitelisting all
systems that need this type, it would be preferable to blacklist the
few that provide same.)
Comments and questions are welcome.
--Daniel
--
Daniel Richard G. || da...@te... || Software Developer
Teragram Linguistic Technologies (a division of SAS)
http://www.teragram.com/ |
|
From: Lucas <mac...@gm...> - 2012-05-10 14:49:25
|
On 05/10/2012 12:52 AM, Raphael Kubo da Costa wrote: > Tim Haynes<th...@op...> writes: > >> On 05/07/2012 08:42 PM, Raphael Kubo da Costa wrote: >>> Hi there, >>> >>> I'm one of the people who package libiodbc on FreeBSD. Recently a user >>> contacted us reporting a crash between libiodbc and Perl's DBD-ODBC >>> module. The original report can be found in >>> <http://forums.freebsd.org/showthread.php?t=31841> >>> >>> The backtrace I got is the one below, with the accompanying trace file >>> obtained by setting Trace = 1 in odbc.ini. >>> >>> Is it something you guys are aware of? >> >> The bug-report is invalid: >> >> [Test] >> Driver = /usr/local/lib/libiodbc.so.3 >> >> I'm not surprised it segfaults if you put the driver manager library as >> the driver. This might also explain the looping between >> SQLDriverConnect() and SQLDriverConnect_Internal() in your stack-trace. >> >> Install an ODBC driver package for the database to which you're trying >> to connect, such as either postgresql-odbc or mysql-connector-odbc (on >> FreeBSD), or similar. > > Thanks for the answer. I guess the original reporter (CC'ed) will be > able to solve his problems now. Yes, I solved this problem by removing ODBC and installing Sybase for Perl. Special thank to Tim Haynes for explaining me the truth. Thank you. |
|
From: Raphael K. da C. <ra...@Fr...> - 2012-05-09 20:52:34
|
Tim Haynes <th...@op...> writes: > On 05/07/2012 08:42 PM, Raphael Kubo da Costa wrote: >> Hi there, >> >> I'm one of the people who package libiodbc on FreeBSD. Recently a user >> contacted us reporting a crash between libiodbc and Perl's DBD-ODBC >> module. The original report can be found in >> <http://forums.freebsd.org/showthread.php?t=31841> >> >> The backtrace I got is the one below, with the accompanying trace file >> obtained by setting Trace = 1 in odbc.ini. >> >> Is it something you guys are aware of? > > The bug-report is invalid: > > [Test] > Driver = /usr/local/lib/libiodbc.so.3 > > I'm not surprised it segfaults if you put the driver manager library as > the driver. This might also explain the looping between > SQLDriverConnect() and SQLDriverConnect_Internal() in your stack-trace. > > Install an ODBC driver package for the database to which you're trying > to connect, such as either postgresql-odbc or mysql-connector-odbc (on > FreeBSD), or similar. Thanks for the answer. I guess the original reporter (CC'ed) will be able to solve his problems now. |
|
From: Tim H. <th...@op...> - 2012-05-09 15:37:04
|
On 05/07/2012 08:42 PM, Raphael Kubo da Costa wrote: > Hi there, > > I'm one of the people who package libiodbc on FreeBSD. Recently a user > contacted us reporting a crash between libiodbc and Perl's DBD-ODBC > module. The original report can be found in > <http://forums.freebsd.org/showthread.php?t=31841> > > The backtrace I got is the one below, with the accompanying trace file > obtained by setting Trace = 1 in odbc.ini. > > Is it something you guys are aware of? The bug-report is invalid: [Test] Driver = /usr/local/lib/libiodbc.so.3 I'm not surprised it segfaults if you put the driver manager library as the driver. This might also explain the looping between SQLDriverConnect() and SQLDriverConnect_Internal() in your stack-trace. Install an ODBC driver package for the database to which you're trying to connect, such as either postgresql-odbc or mysql-connector-odbc (on FreeBSD), or similar. HTH, ~Tim -- Tim Haynes Product Development Consultant OpenLink Software <http://www.openlinksw.com/> <http://twitter.com/openlink> |
|
From: Raphael K. da C. <ra...@Fr...> - 2012-05-07 19:43:01
|
Hi there, I'm one of the people who package libiodbc on FreeBSD. Recently a user contacted us reporting a crash between libiodbc and Perl's DBD-ODBC module. The original report can be found in <http://forums.freebsd.org/showthread.php?t=31841> The backtrace I got is the one below, with the accompanying trace file obtained by setting Trace = 1 in odbc.ini. Is it something you guys are aware of? #0 0x00000008014734a8 in ?? () from /lib/libc.so.7 [570/1924] #1 0x000000080147574b in ?? () from /lib/libc.so.7 #2 0x000000080147a338 in ?? () from /lib/libc.so.7 #3 0x000000080147c47a in malloc () from /lib/libc.so.7 #4 0x0000000801471be9 in strdup () from /lib/libc.so.7 #5 0x000000080285e00f in _iodbcdm_cfg_parse_str_Internal (pconfig=0x8021287b0, str=0x801952b18 "Test") at misc.c:118 #6 0x000000080285e3c9 in _iodbcdm_cfg_parse_str (pconfig=0x8021287b0, str=0x802010d80, size=-3, wide=1) at misc.c:233 #7 0x000000080285e32f in _iodbcdm_cfg_init_str (ppconf=0x7fffffbff910, str=0x802010d80, size=-3, wide=1) at misc.c:210 #8 0x0000000802843d71 in SQLDriverConnect_Internal (hdbc=0x80213b600, hwnd=0x0, szConnStrIn=0x802010d80, cbConnStrIn=-3, szConnStrOut=0x801b14f00, cbConnStrOutMax=512, pcbConnStrOut=0x7fffff ffb8ee, fDriverCompletion=0, waMode=87 'W') at connect.c:2335 #9 0x0000000802846d56 in SQLDriverConnectW (hdbc=0x80213b600, hwnd=0x0, szConnStrIn=0x802010d80 L"Test", cbConnStrIn=-3, szConnStrOut=0x801b14f00 L"", cbConnStrOutMax=512, pcbConnStrOut=0x7f ffffffb8ee, fDriverCompletion=0) at connect.c:3042 #10 0x0000000802844f50 in SQLDriverConnect_Internal (hdbc=0x80213b500, hwnd=0x0, szConnStrIn=0x802010d80, cbConnStrIn=-3, szConnStrOut=0x801b14f00, cbConnStrOutMax=512, pcbConnStrOut=0x7fffff ffb8ee, fDriverCompletion=0, waMode=87 'W') at connect.c:2799 #11 0x0000000802846d56 in SQLDriverConnectW (hdbc=0x80213b500, hwnd=0x0, szConnStrIn=0x802010d80 L"Test", cbConnStrIn=-3, szConnStrOut=0x801b14f00 L"", cbConnStrOutMax=512, pcbConnStrOut=0x7f ffffffb8ee, fDriverCompletion=0) at connect.c:3042 #12 0x0000000802844f50 in SQLDriverConnect_Internal (hdbc=0x80213b400, hwnd=0x0, szConnStrIn=0x802010d80, cbConnStrIn=-3, szConnStrOut=0x801b14f00, cbConnStrOutMax=512, pcbConnStrOut=0x7fffff ffb8ee, fDriverCompletion=0, waMode=87 'W') at connect.c:2799 #13 0x0000000802846d56 in SQLDriverConnectW (hdbc=0x80213b400, hwnd=0x0, szConnStrIn=0x802010d80 L"Test", cbConnStrIn=-3, szConnStrOut=0x801b14f00 L"", cbConnStrOutMax=512, pcbConnStrOut=0x7f ffffffb8ee, fDriverCompletion=0) at connect.c:3042 #14 0x0000000802844f50 in SQLDriverConnect_Internal (hdbc=0x80213b300, hwnd=0x0, szConnStrIn=0x802010d80, cbConnStrIn=-3, szConnStrOut=0x801b14f00, cbConnStrOutMax=512, pcbConnStrOut=0x7fffff ffb8ee, fDriverCompletion=0, waMode=87 'W') at connect.c:2799 #15 0x0000000802846d56 in SQLDriverConnectW (hdbc=0x80213b300, hwnd=0x0, szConnStrIn=0x802010d80 L"Test", cbConnStrIn=-3, szConnStrOut=0x801b14f00 L"", cbConnStrOutMax=512, pcbConnStrOut=0x7f ffffffb8ee, fDriverCompletion=0) at connect.c:3042 #16 0x0000000802844f50 in SQLDriverConnect_Internal (hdbc=0x80213b200, hwnd=0x0, szConnStrIn=0x802010d80, cbConnStrIn=-3, szConnStrOut=0x801b14f00, cbConnStrOutMax=512, pcbConnStrOut=0x7fffff ffb8ee, fDriverCompletion=0, waMode=87 'W') at connect.c:2799 #17 0x0000000802846d56 in SQLDriverConnectW (hdbc=0x80213b200, hwnd=0x0, szConnStrIn=0x802010d80 L"Test", cbConnStrIn=-3, szConnStrOut=0x801b14f00 L"", cbConnStrOutMax=512, pcbConnStrOut=0x7f ffffffb8ee, fDriverCompletion=0) at connect.c:3042 #18 0x0000000802844f50 in SQLDriverConnect_Internal (hdbc=0x80213b100, hwnd=0x0, szConnStrIn=0x802010d80, cbConnStrIn=-3, szConnStrOut=0x801b14f00, cbConnStrOutMax=512, pcbConnStrOut=0x7fffff ffb8ee, fDriverCompletion=0, waMode=87 'W') at connect.c:2799 #19 0x0000000802846d56 in SQLDriverConnectW (hdbc=0x80213b100, hwnd=0x0, szConnStrIn=0x802010d80 L"Test", cbConnStrIn=-3, szConnStrOut=0x801b14f00 L"", cbConnStrOutMax=512, pcbConnStrOut=0x7f ffffffb8ee, fDriverCompletion=0) at connect.c:3042 #20 0x0000000802844f50 in SQLDriverConnect_Internal (hdbc=0x80213b000, hwnd=0x0, szConnStrIn=0x802010d80, cbConnStrIn=-3, szConnStrOut=0x801b14f00, cbConnStrOutMax=512, pcbConnStrOut=0x7fffff ffb8ee, fDriverCompletion=0, waMode=87 'W') at connect.c:2799 #21 0x0000000802846d56 in SQLDriverConnectW (hdbc=0x80213b000, hwnd=0x0, szConnStrIn=0x802010d80 L"Test", cbConnStrIn=-3, szConnStrOut=0x801b14f00 L"", cbConnStrOutMax=512, pcbConnStrOut=0x7f ffffffb8ee, fDriverCompletion=0) at connect.c:3042 #22 0x0000000802844f50 in SQLDriverConnect_Internal (hdbc=0x80213af00, hwnd=0x0, szConnStrIn=0x802010d80, cbConnStrIn=-3, szConnStrOut=0x801b14f00, cbConnStrOutMax=512, pcbConnStrOut=0x7fffff ffb8ee, fDriverCompletion=0, waMode=87 'W') at connect.c:2799 #23 0x0000000802846d56 in SQLDriverConnectW (hdbc=0x80213af00, hwnd=0x0, szConnStrIn=0x802010d80 L"Test", cbConnStrIn=-3, szConnStrOut=0x801b14f00 L"", cbConnStrOutMax=512, pcbConnStrOut=0x7f ffffffb8ee, fDriverCompletion=0) at connect.c:3042 #24 0x0000000802844f50 in SQLDriverConnect_Internal (hdbc=0x80213ae00, hwnd=0x0, szConnStrIn=0x802010d80, cbConnStrIn=-3, szConnStrOut=0x801b14f00, cbConnStrOutMax=512, pcbConnStrOut=0x7fffff ffb8ee, fDriverCompletion=0, waMode=87 'W') at connect.c:2799 #25 0x0000000802846d56 in SQLDriverConnectW (hdbc=0x80213ae00, hwnd=0x0, szConnStrIn=0x802010d80 L"Test", cbConnStrIn=-3, szConnStrOut=0x801b14f00 L"", cbConnStrOutMax=512, pcbConnStrOut=0x7f ffffffb8ee, fDriverCompletion=0) at connect.c:3042 #26 0x0000000802844f50 in SQLDriverConnect_Internal (hdbc=0x80213ad00, hwnd=0x0, szConnStrIn=0x802010d80, cbConnStrIn=-3, szConnStrOut=0x801b14f00, cbConnStrOutMax=512, pcbConnStrOut=0x7fffff ffb8ee, fDriverCompletion=0, waMode=87 'W') at connect.c:2799 #27 0x0000000802846d56 in SQLDriverConnectW (hdbc=0x80213ad00, hwnd=0x0, szConnStrIn=0x802010d80 L"Test", cbConnStrIn=-3, szConnStrOut=0x801b14f00 L"", cbConnStrOutMax=512, pcbConnStrOut=0x7f ffffffb8ee, fDriverCompletion=0) at connect.c:3042 #28 0x0000000802844f50 in SQLDriverConnect_Internal (hdbc=0x80213ac00, hwnd=0x0, szConnStrIn=0x802010d80, cbConnStrIn=-3, szConnStrOut=0x801b14f00, cbConnStrOutMax=512, pcbConnStrOut=0x7fffff ffb8ee, fDriverCompletion=0, waMode=87 'W') at connect.c:2799 #29 0x0000000802846d56 in SQLDriverConnectW (hdbc=0x80213ac00, hwnd=0x0, szConnStrIn=0x802010d80 L"Test", cbConnStrIn=-3, szConnStrOut=0x801b14f00 L"", cbConnStrOutMax=512, pcbConnStrOut=0x7f ffffffb8ee, fDriverCompletion=0) at connect.c:3042 #30 0x0000000802844f50 in SQLDriverConnect_Internal (hdbc=0x80213ab00, hwnd=0x0, szConnStrIn=0x802010d80, cbConnStrIn=-3, szConnStrOut=0x801b14f00, cbConnStrOutMax=512, pcbConnStrOut=0x7fffff ffb8ee, fDriverCompletion=0, waMode=87 'W') at connect.c:2799 #31 0x0000000802846d56 in SQLDriverConnectW (hdbc=0x80213ab00, hwnd=0x0, szConnStrIn=0x802010d80 L"Test", cbConnStrIn=-3, szConnStrOut=0x801b14f00 L"", cbConnStrOutMax=512, pcbConnStrOut=0x7f ffffffb8ee, fDriverCompletion=0) at connect.c:3042 #32 0x0000000802844f50 in SQLDriverConnect_Internal (hdbc=0x80213aa00, hwnd=0x0, szConnStrIn=0x802010d80, cbConnStrIn=-3, szConnStrOut=0x801b14f00, cbConnStrOutMax=512, pcbConnStrOut=0x7fffff ffb8ee, fDriverCompletion=0, waMode=87 'W') at connect.c:2799 ... #310 0x0000000802844f50 in SQLDriverConnect_Internal (hdbc=0x801b99c00, hwnd=0x0, szConnStrIn=0x801a82710, cbConnStrIn=-3, szConnStrOut=0x7fffffffb8f0, cbConnStrOutMax=512, pcbConnStrOut=0x7f ffffffb8ee, fDriverCompletion=0, waMode=65 'A') at connect.c:2799 #311 0x0000000802846891 in SQLDriverConnect (hdbc=0x801b99c00, hwnd=0x0, szConnStrIn=0x801a82710 "Test", cbConnStrIn=4, szConnStrOut=0x7fffffffb8f0 "\021", cbConnStrOutMax=512, pcbConnStrOut= 0x7fffffffb8ee, fDriverCompletion=0) at connect.c:2970 #312 0x0000000802613892 in odbc_db_login6 (dbh=<optimized out>, imp_dbh=<optimized out>, dbname=<optimized out>, uid=<optimized out>, pwd=<optimized out>, attr=<optimized out>) at dbdimp.c:95 4 #313 0x000000080260a348 in XS_DBD__ODBC__db__login (my_perl=<optimized out>, cv=<optimized out>) at /usr/ports/databases/p5-DBD-ODBC/work/DBD-ODBC-1.37/./ODBC.xsi:100 #314 0x00000008008c9a2f in Perl_pp_entersub () from /usr/local/lib/perl5/5.14.2/mach/CORE/libperl.so #315 0x00000008008c7f5e in Perl_runops_standard () from /usr/local/lib/perl5/5.14.2/mach/CORE/libperl.so #316 0x0000000800860877 in Perl_call_sv () from /usr/local/lib/perl5/5.14.2/mach/CORE/libperl.so #317 0x0000000801c0590f in XS_DBI_dispatch (my_perl=0x80181ab00, cv=0x801b03ac8) at /usr/ports/databases/p5-DBI/work/DBI-1.620/DBI.xs:3688 #318 0x00000008008c9a2f in Perl_pp_entersub () from /usr/local/lib/perl5/5.14.2/mach/CORE/libperl.so #319 0x00000008008c7f5e in Perl_runops_standard () from /usr/local/lib/perl5/5.14.2/mach/CORE/libperl.so #320 0x00000008008615f1 in perl_run () from /usr/local/lib/perl5/5.14.2/mach/CORE/libperl.so #321 0x0000000000400ede in main () ** iODBC Trace file ** Trace started on Mon May 07 16:30:35 2012 ** Driver Manager: 03.52.0812.0326 [000000.003315] Application 801807400 ENTER SQLAllocHandle SQLSMALLINT 1 (SQL_HANDLE_ENV) SQLHANDLE 0x0 (SQL_NULL_HANDLE) SQLHANDLE * 0x802138ee0 [000000.003572] Application 801807400 EXIT SQLAllocHandle with return code 0 (SQL_SUCCESS) SQLSMALLINT 1 (SQL_HANDLE_ENV) SQLHANDLE 0x0 (SQL_NULL_HANDLE) SQLHANDLE * 0x802138ee0 (0x80213f830) [000000.003796] Application 801807400 ENTER SQLSetEnvAttr SQLHENV 0x80213f830 SQLINTEGER 200 (SQL_ATTR_ODBC_VERSION) SQLPOINTER 0x3 SQLINTEGER * 0 [000000.004050] Application 801807400 EXIT SQLSetEnvAttr with return code 0 (SQL_SUCCESS) SQLHENV 0x80213f830 SQLINTEGER 200 (SQL_ATTR_ODBC_VERSION) SQLPOINTER 0x3 SQLINTEGER * 0 [000000.004304] Application 801807400 ENTER SQLAllocHandle SQLSMALLINT 2 (SQL_HANDLE_DBC) SQLHANDLE 0x80213f830 SQLHANDLE * 0x802141528 [000000.004497] Application 801807400 EXIT SQLAllocHandle with return code 0 (SQL_SUCCESS) SQLSMALLINT 2 (SQL_HANDLE_DBC) SQLHANDLE 0x80213f830 SQLHANDLE * 0x802141528 (0x802141600) [000000.004752] Application 801807400 ENTER SQLDriverConnectW SQLHDBC 0x802141600 SQLPOINTER 0x0 SQLWCHAR * 0x802014dc0 SQLSMALLINT -3 (SQL_NTS) SQLWCHAR * 0x801b1af00 SQLSMALLINT 512 SQLSMALLINT * 0x7fffffffb90e SQLUSMALLINT 0 (SQL_DRIVER_NOPROMPT) |
|
From: Tim H. <th...@op...> - 2012-03-28 11:38:58
|
Hi, OpenLink Software are pleased to announce the release of the iODBC Driver Manager, version 3.52.8. This version sees the project hosting transferred to GitHub for future development and the conversion of Mac OS X UI to XIB format for Mac OS X 10.5and newer versions. Fixes include an issue with tracing multiple chunks inSQLGetData; an issue with tracing on big-endian machines; an issue with using previously freed memory; other minor bug fixes. Developers who want to actively track progress of the iODBC source code and contribute bug fixes or enhancements to the project are cordially invited to join us at: <http://github.com/openlink/iODBC> Website: http://www.iodbc.org/ Regards, ~Tim -- Tim Haynes Product Development Consultant OpenLink Software <http://www.openlinksw.com/> <http://twitter.com/openlink> |
|
From: Patrick v. K. <pk...@op...> - 2012-03-12 21:47:13
|
Hi Marian, > The problem seems to be a self death locking on the mutex. > For example if i add this change to ENTER_HDBC() > (not trying to lock if already done so) > > #define ENTER_HDBC(hdbc, holdlock, trace) \ > CONN(pdbc, hdbc); \ > SQLRETURN retcode = SQL_SUCCESS; \ > if (!holdlock) \ > ODBC_LOCK();\ > > The first hung that i reported looks clean now. > The application hangs at the next recursive lock i see. > > > #0 0x00007ffff57d9c74 in __lll_lock_wait () from /lib/libpthread.so.0 > #1 0x00007ffff57d5179 in _L_lock_953 () from /lib/libpthread.so.0 > #2 0x00007ffff57d4f9b in pthread_mutex_lock () from /lib/libpthread.so.0 > #3 0x00007ffff7baaf4c in SQLErrorW (henv=<value optimized out>, > hdbc=0x80, hstmt=0x0, szSqlstate=0xffffffffffffffff <Address > 0xffffffffffffffff out of bounds>, > pfNativeError=0x7ffff7dde920, szErrorMsg=0x4251 <Address 0x4251 out of > bounds>, cbErrorMsgMax=0, pcbErrorMsg=0x7fffffffbc5e) at herr.c:699 > #4 0x00007ffff7baa01f in SQLGetDiagRec_Internal (HandleType=2, > Handle=0x9caea0, RecNumber=<value optimized out>, Sqlstate=0x7fffffffb7a0, > NativeErrorPtr=<value optimized out>, > MessageText=0x0, BufferLength=0, TextLengthPtr=0x7fffffffbc5e, > waMode=87 'W') at herr.c:1029 > #5 0x00007ffff7baa157 in SQLGetDiagRecW (HandleType=<value optimized > out>, Handle=0x9caea0, RecNumber=<value optimized out>, > Sqlstate=0x7fffffffb7a0 L"\x800000", > NativeErrorPtr=0x7fffffffbc58, MessageText=0x0, BufferLength=0, > TextLengthPtr=0x7fffffffbc5e) at herr.c:1181 > > > Here is the log for this run. I am not sure why running postgresql is > different that mysql which works ok. > > I have tested this with iODBC libiodbc-3.52.7 and postgresql ODBC > psqlodbc-09.01.0100 (but i was able to reproduce this with older versions > too). > I examined your trace and i found the following issue: [000000.011632] tksqlGUI 7FE62BD62720 ENTER SQLAllocHandle SQLSMALLINT 3 (SQL_HANDLE_STMT) SQLHANDLE 0x22fde50 SQLHANDLE * 0x7fff6a6d9010 [000000.011655] tksqlGUI 7FE62BD62720 ENTER SQLAllocStmt SQLHDBC 0x2321160 SQLHSTMT * 0x2310b18 This first call is coming from your application which is requesting a statement handle. The iODBC driver manager locks the appropriate mutex, looks up the appropriate function in the driver (postgresql) and call. Since postgresql driver has an implementation of this call, it will call the SQLAllocHandle code inside the driver. However the driver appears try and call the SQLAllocStmt function, but unfortunately the driver does not pick up it's own copy of that function, but calls the iODBC driver managers function. This tries to set the same mutex that the first call has already locked and therefor you get a mutex deadlock situation. This is bad driver design since a driver should not call itself through the outside API to exactly avoid this issue. This does not only affect mutexes, but also can mix internal handles (between the driver and the driver manager) with external handles (between the driver manager and the application) which may differ in places. If your app is single threaded it would be easy to rebuild iODBC without any thread-safe features, but that still might leave you vulnerable to this issue of internal/external handles. If you tell me the platform you are working on, i can see if there is a way around this, so when the drivers symbols are resolved, they are resolved to it's internal rather than public functions. That is the only way to properly resolve this problem. Patrick > > >> Hi Marian, >> >>> >>> >>> I am running into a death lock with iODBC and postgreSQL for function >>> SQLAllocStmt(). >>> The stack in the always the same and it hangs when SQLAllocStmt() is >>> reached. >>> >>> The same code works with unixODBC. Is there any way to baypass that >>> lock ? Anyone seen this problem before ? >>> >>> >>> #0 0x00007f2113f4ec74 in __lll_lock_wait () from >>> /usr/local/thekompany/lib/libpthread.so.0 >>> #1 0x00007f2113f4a179 in _L_lock_953 () from >>> /usr/local/thekompany/lib/libpthread.so.0 >>> #2 0x00007f2113f49f9b in pthread_mutex_lock () from >>> /usr/local/thekompany/lib/libpthread.so.0 >>> #3 0x00007f2116580f72 in SQLAllocStmt (hdbc=0x2dd47c0, phstmt=0x80) at >>> hstmt.c:427 >>> #4 0x00007f2116580a08 in SQLAllocStmt_Internal (hdbc=0x2a03670, >>> phstmt=0x2d91750) at hstmt.c:241 >>> #5 0x00007f2116590d32 in SQLAllocHandle (handleType=3, >>> inputHandle=0x2a03670, outputHandlePtr=0x2d91750) at odbc3.c:276 >>> >> >> What version of iODBC are you using at this time. Also it will help if I >> know either version of the PostgreSQL ODBC driver you are using as well as >> the OS. >> >> Also please add the following lines to your ODBC.ini file: >> >> [ODBC] >> TraceFile = /tmp/iodbc.log >> Trace =1 >> >> Next run your app again and send me the output of this trace for analysis >> as well. >> >> >> Patrick >> -- >> OpenLink Software > <odbc.log>------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/_______________________________________________ > Iodbc-bugs mailing list > Iod...@li... > https://lists.sourceforge.net/lists/listinfo/iodbc-bugs |
88 messages has been excluded from this view by a project administrator.
