Bug#354723: unixodbc: fails to retrieve data from ODBC connection
Yes, and it seems to not be a bug in unixodbc. Reassigning to rodbc.
I am just rebuilding R with the nostrip option because this is what I am
really interested in.
The only segfault you reported was in php; I don't see that rebuilding R
with debugging symbols will be particularly useful. A backtrace of the php
segfault, with or without debugging symbols, may be helpful, but that's a
separate bug from the rodbc bug.
You are right, I was not thinking. Now I can't get the backtrace of the
php segfault:
[EMAIL PROTECTED]:~$ cat odbctest.php
?php
$dbh = odbc_connect('cytotox', 'cytotox', 'cytotox') or
die(odbc_errormsg() );
?
[EMAIL PROTECTED]:~$ php odbctest.php
Speicherzugriffsfehler
(gdb) shell php odbctest.php
(gdb)
gdb does not tell me anything. Sorry for my ignorance.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354723: Processed: Re: Bug#354723: unixodbc: fails to retrieve data from ODBC connection
Did you try setting believeNRows=FALSE in odbcConnect() ? From help(odbcConnect, package=RODBC): odbcConnect(dsn, uid = , pwd = , case = nochange, believeNRows = TRUE) [...] believeNRows: logical. Is the number of rows returned by the ODBC connection believable? Not true for Oracle and Sybase, apparently. This has been the fix on other systems, it could simply that RODBC gets handed a bad value. Apparently common with some backends, as I recall I had to use that too with some Sybase-on-Solaris versions a while back. Yes, I have tried this with the exact same result. I have to stress that this only happens on ONE of my systems (pure amd64). Probably something really stupid but I just can't get it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354723: unixodbc: fails to retrieve data from ODBC connection
On Thu, Mar 02, 2006 at 09:06:27AM +0100, Johannes Ranke wrote:
Yes, and it seems to not be a bug in unixodbc. Reassigning to rodbc.
I am just rebuilding R with the nostrip option because this is what I am
really interested in.
The only segfault you reported was in php; I don't see that rebuilding R
with debugging symbols will be particularly useful. A backtrace of the php
segfault, with or without debugging symbols, may be helpful, but that's a
separate bug from the rodbc bug.
You are right, I was not thinking. Now I can't get the backtrace of the
php segfault:
[EMAIL PROTECTED]:~$ cat odbctest.php
?php
$dbh = odbc_connect('cytotox', 'cytotox', 'cytotox') or
die(odbc_errormsg() );
?
[EMAIL PROTECTED]:~$ php odbctest.php
Speicherzugriffsfehler
(gdb) shell php odbctest.php
(gdb)
gdb does not tell me anything. Sorry for my ignorance.
The expected commands are gdb php, followed by run odbctest.php and
bt.
I would clone this bug and reassign a copy to the php odbc package, but I
don't see that you've mentioned which version of php you're using.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
Bug#354723: unixodbc: fails to retrieve data from ODBC connection
The expected commands are gdb php, followed by run odbctest.php and bt. I would clone this bug and reassign a copy to the php odbc package, but I don't see that you've mentioned which version of php you're using. Thanks for the debugging primers. Meanwhile I recompiled libmyodbc against libmysqlclient15-dev. The Problem is gone. If I reinstall libmyodbc from the archive, it reappears. So in this case the problem is the outdated build-dependency of libmyodbc. I believe this i related to the libmyodbc bug #353997 (where you concluded that the build-dependency should be fixed). Now I also get a backtrace, which is attached. GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-linux-gnu...Using host libthread_db library /lib/libthread_db.so.1. (gdb) run odbctest.php Starting program: /usr/bin/php odbctest.php [Thread debugging using libthread_db enabled] [New Thread 46912527266000 (LWP 30918)] Program exited normally. (gdb) bt No stack. (gdb) quit [EMAIL PROTECTED]:~$ php odbc.php Could not open input file: odbc.php [EMAIL PROTECTED]:~$ php odbctest.php [EMAIL PROTECTED]:~$ php odbctest.php Speicherzugriffsfehler [EMAIL PROTECTED]:~$ gdb php GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-linux-gnu...Using host libthread_db library /lib/libthread_db.so.1. (gdb) run odbctest.php Starting program: /usr/bin/php odbctest.php [Thread debugging using libthread_db enabled] [New Thread 46912527266000 (LWP 30987)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46912527266000 (LWP 30987)] 0x2cb9d5e2 in mysql_free_result () from /usr/lib/libmysqlclient.so.15 (gdb) bt #0 0x2cb9d5e2 in mysql_free_result () from /usr/lib/libmysqlclient.so.15 #1 0x2d7c4e5c in my_SQLFreeStmt () from /usr/lib/odbc/libmyodbc.so #2 0x2d7bf137 in my_SQLDisconnect () from /usr/lib/odbc/libmyodbc.so #3 0x2d7bf1d9 in SQLDisconnect () from /usr/lib/odbc/libmyodbc.so #4 0x2cef6093 in SQLDisconnect () from /usr/lib/libodbc.so.1 #5 0x2cdae729 in get_module () from /usr/lib/php5/20051025/odbc.so #6 0x2cdae78f in get_module () from /usr/lib/php5/20051025/odbc.so #7 0x006216fe in list_entry_destructor (ptr=0x735f316e6974616c) at /home/ranke/tmp/php5-5.1.2/Zend/zend_list.c:184 #8 0x00620599 in zend_hash_del_key_or_index (ht=0xa2f9e8, arKey=0x0, nKeyLength=2897860048, h=30987, flag=-1392243520) at /home/ranke/tmp/php5-5.1.2/Zend/zend_hash.c:490 #9 0x00621369 in _zend_list_delete (id=1769234796) at /home/ranke/tmp/php5-5.1.2/Zend/zend_list.c:58 #10 0x006096d7 in _zval_ptr_dtor (zval_ptr=0xbb2580) at /home/ranke/tmp/php5-5.1.2/Zend/zend_variables.h:35 #11 0x0061f0da in zend_hash_apply_deleter (ht=0xa2f828, p=0xbb2568) at /home/ranke/tmp/php5-5.1.2/Zend/zend_hash.c:574 #12 0x0061f258 in zend_hash_graceful_reverse_destroy (ht=0xa2f828) at /home/ranke/tmp/php5-5.1.2/Zend/zend_hash.c:640 #13 0x00609549 in shutdown_executor () at /home/ranke/tmp/php5-5.1.2/Zend/zend_execute_API.c:217 #14 0x006156a7 in zend_deactivate () at /home/ranke/tmp/php5-5.1.2/Zend/zend.c:846 #15 0x005d7bca in php_request_shutdown (dummy=0x735f316e6974616c) at /home/ranke/tmp/php5-5.1.2/main/main.c:1284 #16 0x006ad0f6 in main (argc=32767, argv=0x2abc2880) at /home/ranke/tmp/php5-5.1.2/sapi/cli/php_cli.c:1230 (gdb)
Bug#354723: Processed: Re: Bug#354723: unixodbc: fails to retrieve data from ODBC connection
On 1 March 2006 at 22:30, Dirk Eddelbuettel wrote: | Did you try setting believeNRows=FALSE in odbcConnect() ? From | help(odbcConnect, package=RODBC): [...] | odbcConnect(dsn, uid = , pwd = , case = nochange, | believeNRows = TRUE) | [...] | believeNRows: logical. Is the number of rows returned by the ODBC | connection believable? Not true for Oracle and Sybase, | apparently. | | This has been the fix on other systems, it could simply that RODBC gets | handed a bad value. Apparently common with some backends, as I recall I had | to use that too with some Sybase-on-Solaris versions a while back. I really meant FALSE, not TRUE: On 2 March 2006 at 10:00, Johannes Ranke wrote: | Package: r-cran-rodbc | Version: 1.1.5-1 | Followup-For: Bug #354723 [...] | [EMAIL PROTECTED]:~$ cat odbctest.R | library(RODBC) | channel - odbcConnect(cytotox,uid=cytotox, | pwd=cytotox, believeNRows=TRUE) ^^ | query - SELECT plate FROM plates LIMIT 1,10 | tables - sqlQuery(channel,query) | tables | odbcGetErrMsg(channel) | odbcClose(channel) So could you please try with FALSE? Otherwise, I agree with a comment you made in the another mail that it is probably the myodbc driver that causes it. RODBC only passes the command on. Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354723: Processed: Re: Bug#354723: unixodbc: fails to retrieve data from ODBC connection
* Dirk Eddelbuettel [EMAIL PROTECTED] [060302 13:30]: On 1 March 2006 at 22:30, Dirk Eddelbuettel wrote: | Did you try setting believeNRows=FALSE in odbcConnect() ? From | help(odbcConnect, package=RODBC): [...] | odbcConnect(dsn, uid = , pwd = , case = nochange, | believeNRows = TRUE) | [...] | believeNRows: logical. Is the number of rows returned by the ODBC | connection believable? Not true for Oracle and Sybase, | apparently. | | This has been the fix on other systems, it could simply that RODBC gets | handed a bad value. Apparently common with some backends, as I recall I had | to use that too with some Sybase-on-Solaris versions a while back. I really meant FALSE, not TRUE: On 2 March 2006 at 10:00, Johannes Ranke wrote: | Package: r-cran-rodbc | Version: 1.1.5-1 | Followup-For: Bug #354723 [...] | [EMAIL PROTECTED]:~$ cat odbctest.R | library(RODBC) | channel - odbcConnect(cytotox,uid=cytotox, | pwd=cytotox, believeNRows=TRUE) ^^ | query - SELECT plate FROM plates LIMIT 1,10 | tables - sqlQuery(channel,query) | tables | odbcGetErrMsg(channel) | odbcClose(channel) So could you please try with FALSE? Hi again, as I said something in the mess above, I DID try with FALSE, here it is library(RODBC) channel - odbcConnect(cytotox,uid=cytotox, + pwd=cytotox, believeNRows=FALSE) query - SELECT plate FROM plates LIMIT 1,10 tables - sqlQuery(channel,query) tables character(0) odbcGetErrMsg(channel) character(0) odbcClose(channel) Otherwise, I agree with a comment you made in the another mail that it is probably the myodbc driver that causes it. RODBC only passes the command on. I could fix the problem of the segfault of php5-odbc by recompiling libmyodbc (I will add this story to #353997, which is the same bug) But on this, I am still working. The following strace comparison between working (i386 box) and failing (amd64 box) might be useful: i386 ... write(1, query - \SELECT plate FROM pl..., 49 query - SELECT plate FROM plates LIMIT 1,10 ) = 49 write(1, tables - sqlQuery(channel,que..., 36 tables - sqlQuery(channel,query) ) = 36 semop(98306, 0xbfd50c90, 2) = 0 semop(98306, 0xbfd50c9e, 1) = 0 time(NULL) = 1141300906 fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 read(3, 0x86086c0, 8192)= -1 EAGAIN (Resource temporarily unavailable) fcntl64(3, F_SETFL, O_RDWR) = 0 write(3, $\0\0\0\3SELECT plate FROM plates LI..., 40) = 40 read(3, \1\0\0\1, 4) = 4 read(3, \1, 1)= 1 read(3, \27\0\0\2, 4) = 4 read(3, \6plates\5plate\3\v\0\0\1\3\3\0\0\0, 23) = 23 read(3, \1\0\0\3, 4) = 4 read(3, \376, 1) = 1 read(3, \2\0\0\4, 4) = 4 read(3, \0014, 2) = 2 read(3, \2\0\0\5, 4) = 4 read(3, \0015, 2) = 2 read(3, \2\0\0\6, 4) = 4 read(3, \0016, 2) = 2 read(3, \2\0\0\7, 4) = 4 read(3, \0018, 2) = 2 ... amd64: ... write(1, query - \SELECT plate FROM pl..., 49 query - SELECT plate FROM plates LIMIT 1,10 ) = 49 write(1, tables - sqlQuery(channel,que..., 36 tables - sqlQuery(channel,query) ) = 36 semop(32769, 0x16d1d08, 140737486958608) = 0 semop(32769, 0x16d1d08, 140737486958608) = 0 fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)= 0 read(3, 0xb508b0, 8192) = -1 EAGAIN (Resource temporarily unavailable) fcntl(3, F_SETFL, O_RDWR) = 0 write(3, $\0\0\0\3SELECT plate FROM plates LI..., 40) = 40 read(3, \1\0\0\1\0013\0\0\2\3def\7cytotox\6plates\6pla..., 16384) = 144 write(1, tables\n, 9 tables ) = 9 write(1, character(0)\n, 13character(0) ) = 13 ... It tells me that mysql returns lots of data, which is not correctly read by whatever reads it. It can't really be myODBC, because I can retrieve the data with isql, as I demonstrated above. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354723: Processed: Re: Bug#354723: unixodbc: fails to retrieve data from ODBC connection
On 2 March 2006 at 13:46, Johannes Ranke wrote: | | * Dirk Eddelbuettel [EMAIL PROTECTED] [060302 13:30]: | | On 1 March 2006 at 22:30, Dirk Eddelbuettel wrote: | | Did you try setting believeNRows=FALSE in odbcConnect() ? From | | help(odbcConnect, package=RODBC): | [...] | | odbcConnect(dsn, uid = , pwd = , case = nochange, | | believeNRows = TRUE) | | [...] | | believeNRows: logical. Is the number of rows returned by the ODBC | | connection believable? Not true for Oracle and Sybase, | | apparently. | | | | This has been the fix on other systems, it could simply that RODBC gets | | handed a bad value. Apparently common with some backends, as I recall I had | | to use that too with some Sybase-on-Solaris versions a while back. | | I really meant FALSE, not TRUE: | | On 2 March 2006 at 10:00, Johannes Ranke wrote: | | Package: r-cran-rodbc | | Version: 1.1.5-1 | | Followup-For: Bug #354723 | [...] | | [EMAIL PROTECTED]:~$ cat odbctest.R | | library(RODBC) | | channel - odbcConnect(cytotox,uid=cytotox, | | pwd=cytotox, believeNRows=TRUE) | ^^ | | query - SELECT plate FROM plates LIMIT 1,10 | | tables - sqlQuery(channel,query) | | tables | | odbcGetErrMsg(channel) | | odbcClose(channel) | | So could you please try with FALSE? | | Hi again, | | as I said something in the mess above, I DID try with FALSE, here it is Sorry, I must have mised that. | | library(RODBC) | channel - odbcConnect(cytotox,uid=cytotox, | + pwd=cytotox, believeNRows=FALSE) | query - SELECT plate FROM plates LIMIT 1,10 | tables - sqlQuery(channel,query) | tables | character(0) | odbcGetErrMsg(channel) | character(0) | odbcClose(channel) I see. | Otherwise, I agree with a comment you made in the another mail that it is | probably the myodbc driver that causes it. RODBC only passes the command on. | | I could fix the problem of the segfault of php5-odbc by recompiling | libmyodbc (I will add this story to #353997, which is the same bug) I am still lost. So is this, or isn't this, one bug report. | But on this, I am still working. The following strace comparison between | working (i386 box) and failing (amd64 box) might be useful: I am not exactly sure how this would help me. I need one reproducable bug report. As you said yourself, RODBC works on all your other platforms, and I never had complaints from any other amd64 user ... so I'd really like something tangible before I go to the upstream maintainer with this. Sorry for all yoru troubles, and thanks for the help. Dirk | i386 | | ... | write(1, query - \SELECT plate FROM pl..., 49 query - SELECT plate FROM plates LIMIT 1,10 | ) = 49 | write(1, tables - sqlQuery(channel,que..., 36 tables - sqlQuery(channel,query) | ) = 36 | semop(98306, 0xbfd50c90, 2) = 0 | semop(98306, 0xbfd50c9e, 1) = 0 | time(NULL) = 1141300906 | fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 | read(3, 0x86086c0, 8192)= -1 EAGAIN (Resource temporarily unavailable) | fcntl64(3, F_SETFL, O_RDWR) = 0 | write(3, $\0\0\0\3SELECT plate FROM plates LI..., 40) = 40 | read(3, \1\0\0\1, 4) = 4 | read(3, \1, 1)= 1 | read(3, \27\0\0\2, 4) = 4 | read(3, \6plates\5plate\3\v\0\0\1\3\3\0\0\0, 23) = 23 | read(3, \1\0\0\3, 4) = 4 | read(3, \376, 1) = 1 | read(3, \2\0\0\4, 4) = 4 | read(3, \0014, 2) = 2 | read(3, \2\0\0\5, 4) = 4 | read(3, \0015, 2) = 2 | read(3, \2\0\0\6, 4) = 4 | read(3, \0016, 2) = 2 | read(3, \2\0\0\7, 4) = 4 | read(3, \0018, 2) = 2 | ... | | amd64: | | ... | write(1, query - \SELECT plate FROM pl..., 49 query - SELECT plate FROM plates LIMIT 1,10 | ) = 49 | write(1, tables - sqlQuery(channel,que..., 36 tables - sqlQuery(channel,query) | ) = 36 | semop(32769, 0x16d1d08, 140737486958608) = 0 | semop(32769, 0x16d1d08, 140737486958608) = 0 | fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)= 0 | read(3, 0xb508b0, 8192) = -1 EAGAIN (Resource temporarily unavailable) | fcntl(3, F_SETFL, O_RDWR) = 0 | write(3, $\0\0\0\3SELECT plate FROM plates LI..., 40) = 40 | read(3, \1\0\0\1\0013\0\0\2\3def\7cytotox\6plates\6pla..., 16384) = 144 | write(1, tables\n, 9 tables | ) = 9 | write(1, character(0)\n, 13character(0) | ) = 13 | | ... | | It tells me that mysql returns lots of data, which is not correctly read | by whatever reads it. It can't really be myODBC, because I can retrieve | the data with isql, as I demonstrated above. -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email
Bug#354723: Processed: Re: Bug#354723: unixodbc: fails to retrieve data from ODBC connection
| I could fix the problem of the segfault of php5-odbc by recompiling | libmyodbc (I will add this story to #353997, which is the same bug) I am still lost. So is this, or isn't this, one bug report. OK, this wasn't clear. I meant, the problem with php5-odbc is the same as in #353997. The problem with RODBC is not fixed by recompiling libmyodbc, and must therefore have a different reason. | But on this, I am still working. The following strace comparison between | working (i386 box) and failing (amd64 box) might be useful: I am not exactly sure how this would help me. I need one reproducable bug report. ACK. As you said yourself, RODBC works on all your other platforms, and I never had complaints from any other amd64 user ... so I'd really like something tangible before I go to the upstream maintainer with this. Well, it is quite tangible for me, inasmuch as I can't work with RODBC on this machine. I use it a lot. And it used to work before. Unfortunately I can't associate the appearance of the bug with any upgrade. Probably it's something trivial. Maybe the locale settings. I understand you don't want to involve BDR. I will keep on thinking. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354723: unixodbc: fails to retrieve data from ODBC connection
reassign 354723 r-cran-rodbc thanks On Wed, Mar 01, 2006 at 02:01:35AM +0100, Johannes Ranke wrote: strace is useless for debugging a segfault. Please run your test script under gdb and forward the backtrace. http://wiki.debian.org/HowToGetABacktrace OK, thanks for the hint! I just wanted to install the build-deps for php5-odbc but then it wanted to deinstall a couple of things: stiller:~/tmp# LANG=en_EN apt-get build-dep php5-odbc Reading package lists... Done Building dependency tree... Done The following packages will be REMOVED: flex-old libdb3-dev libgnome-dev libmysqlclient12-dev flex-old and libmysqlclient12-dev were build-deps of unixodbc which I rebuilt earlier today. I guess that's the problem. So I would like to focus on RODBC: but if I use the correct column name, it returns an empty set query - select plate from plates tables - sqlQuery(channel,query,errors=TRUE) tables character(0) odbcGetErrMsg(channel) character(0) although the same query issued with the mysql command line client (and same username and password) gives 1202 rows. And what happens if you issue the query using the isql commandline tool? Then it also gives 1202 rows! So it seems to be a coincidence that both RODBC and php5-odbc are messed up on my system. Yes, and it seems to not be a bug in unixodbc. Reassigning to rodbc. I didn't know isql so far, although I was looking for something like this - it's great! I am just rebuilding R with the nostrip option because this is what I am really interested in. The only segfault you reported was in php; I don't see that rebuilding R with debugging symbols will be particularly useful. A backtrace of the php segfault, with or without debugging symbols, may be helpful, but that's a separate bug from the rodbc bug. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#354723: Processed: Re: Bug#354723: unixodbc: fails to retrieve data from ODBC connection
I just inherited this bug report. As I understand ODBC, the actual lifting is done by the ODBC driver of the RDBMS -- here MySQL. My casual look seems to indicate that the segfault is there, so neither a r-cran-rodbc bug, nor (as Steve determined) a odbcconfig bug. But why r-cran-rodbc? That package has been very stable upstream, and generally solid. Dirk On 1 March 2006 at 16:18, Debian Bug Tracking System wrote: | Processing commands for [EMAIL PROTECTED]: | | reassign 354723 r-cran-rodbc | Bug#354723: unixodbc: fails to retrieve data from ODBC connection | Bug reassigned from package `unixodbc' to `r-cran-rodbc'. | | thanks | Stopping processing here. | | Please contact me if you need assistance. | | Debian bug tracking system administrator | (administrator, Debian Bugs database) | -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354723: Processed: Re: Bug#354723: unixodbc: fails to retrieve data from ODBC connection
On Wed, Mar 01, 2006 at 09:00:02PM -0600, Dirk Eddelbuettel wrote: I just inherited this bug report. As I understand ODBC, the actual lifting is done by the ODBC driver of the RDBMS -- here MySQL. My casual look seems to indicate that the segfault is there, so neither a r-cran-rodbc bug, nor (as Steve determined) a odbcconfig bug. But why r-cran-rodbc? That package has been very stable upstream, and generally solid. Because the behavior when trying to issue a query using r-cran-rodbc is *not* a segfault, it's simply a failure to return the data, and this behavior was not reproducible with isql. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#354723: Processed: Re: Bug#354723: unixodbc: fails to retrieve data from ODBC connection
On 1 March 2006 at 19:06, Steve Langasek wrote: | On Wed, Mar 01, 2006 at 09:00:02PM -0600, Dirk Eddelbuettel wrote: | | I just inherited this bug report. As I understand ODBC, the actual lifting is | done by the ODBC driver of the RDBMS -- here MySQL. My casual look seems to | indicate that the segfault is there, so neither a r-cran-rodbc bug, nor (as | Steve determined) a odbcconfig bug. | | But why r-cran-rodbc? That package has been very stable upstream, and | generally solid. | | Because the behavior when trying to issue a query using r-cran-rodbc is | *not* a segfault, it's simply a failure to return the data, and this | behavior was not reproducible with isql. Could you point me to a reproducible example? This would help me greatly in bringing this up with upstream. Dirk, swamped as I just did a Quantian release -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354723: Processed: Re: Bug#354723: unixodbc: fails to retrieve data from ODBC connection
Johannes, On 1 March 2006 at 19:06, Steve Langasek wrote: | On Wed, Mar 01, 2006 at 09:00:02PM -0600, Dirk Eddelbuettel wrote: | | I just inherited this bug report. As I understand ODBC, the actual lifting is | done by the ODBC driver of the RDBMS -- here MySQL. My casual look seems to | indicate that the segfault is there, so neither a r-cran-rodbc bug, nor (as | Steve determined) a odbcconfig bug. | | But why r-cran-rodbc? That package has been very stable upstream, and | generally solid. | | Because the behavior when trying to issue a query using r-cran-rodbc is | *not* a segfault, it's simply a failure to return the data, and this | behavior was not reproducible with isql. Did you try setting believeNRows=FALSE in odbcConnect() ? From help(odbcConnect, package=RODBC): odbcConnect(dsn, uid = , pwd = , case = nochange, believeNRows = TRUE) [...] believeNRows: logical. Is the number of rows returned by the ODBC connection believable? Not true for Oracle and Sybase, apparently. This has been the fix on other systems, it could simply that RODBC gets handed a bad value. Apparently common with some backends, as I recall I had to use that too with some Sybase-on-Solaris versions a while back. Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354723: unixodbc: fails to retrieve data from ODBC connection
Package: unixodbc
Version: 2.2.11-9
Severity: important
The combination of unixodbc, libmyodbc and r-cran-rodbc works nicely on
a couple of i386 (debian unstable) and one amd64 (debian stable) boxes.
On this machine, I am running pure amd64 unstable, and I get a very
strange behavior with ODBC connections to my local mysql database:
A php test script
?php
$dbh = odbc_connect('cytotox', 'cytotox', 'cytotox') or
die(odbc_errormsg() );
?
just segfaults. strace ends with
a_family=AF_INET, sin_port=htons(3306),
sin_addr=inet_addr(127.0.0.1)}, 16) = 0
setsockopt(3, SOL_IP, IP_TOS, [53983375223947272], 4) = 0
setsockopt(3, SOL_TCP, TCP_NODELAY, [53983375223947265], 4) = 0
setsockopt(3, SOL_SOCKET, SO_KEEPALIVE, [-6000514326958440447], 4) = 0
read(3, A\0\0\0\n5.0.18-Debian_8-log\0,\0\0\0?b..., 16384) = 69
stat(/usr/share/mysql/charsets/Index.xml, {st_mode=S_IFREG|0644,
st_size=18171, ...}) = 0
open(/usr/share/mysql/charsets/Index.xml, O_RDONLY) = 4
read(4, ?xml version=\'1.0\' encoding=\ut..., 18171) = 18171
close(4)= 0
write(3, [EMAIL PROTECTED]...,
73) = 73
read(3, \1\0\0\2\376, 16384) = 5
write(3, [EMAIL PROTECTED], 13) = 13
read(3, \7\0\0\4\0\0\0\2\0\0\0, 16384) = 11
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
An R test script
library(RODBC)
channel - odbcConnect(cytotox,uid=cytotox,
pwd=cytotox)
odbcGetInfo(channel)
query - select plates from plates
tables - sqlQuery(channel,query,errors=TRUE)
tables
odbcGetErrMsg(channel)
odbcClose(channel)
shows an error message if the SQL Query can not be executed because of
an unknown column name:
tables - sqlQuery(channel,query,errors=TRUE)
tables
[1] [RODBC] ERROR: Could not SQLExecDirect
[2] S0022 1054 [unixODBC][MySQL][ODBC 3.51
Driver][mysqld-5.0.18-Debian_8-log]Unknown column 'plates' in 'field
list'
but if I use the correct column name, it returns an empty set
query - select plate from plates
tables - sqlQuery(channel,query,errors=TRUE)
tables
character(0)
odbcGetErrMsg(channel)
character(0)
although the same query issued with the mysql command line client (and
same username and password) gives 1202 rows.
I don't know how to debug this. Any comments welcome!
Johannes Ranke
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13.4-stiller1
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Versions of packages unixodbc depends on:
ii libc6 2.3.6-1GNU C Library: Shared libraries an
ii libltdl3 1.5.22-2 A system independent dlopen wrappe
ii libreadline5 5.1-6 GNU readline and history libraries
ii odbcinst1debian1 2.2.11-9 Support library and helper program
unixodbc recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354723: unixodbc: fails to retrieve data from ODBC connection
On Tue, Feb 28, 2006 at 02:59:36PM +0100, Johannes Ranke wrote:
Package: unixodbc
Version: 2.2.11-9
Severity: important
The combination of unixodbc, libmyodbc and r-cran-rodbc works nicely on
a couple of i386 (debian unstable) and one amd64 (debian stable) boxes.
On this machine, I am running pure amd64 unstable, and I get a very
strange behavior with ODBC connections to my local mysql database:
A php test script
?php
$dbh = odbc_connect('cytotox', 'cytotox', 'cytotox') or
die(odbc_errormsg() );
?
just segfaults. strace ends with
strace is useless for debugging a segfault. Please run your test script
under gdb and forward the backtrace.
http://wiki.debian.org/HowToGetABacktrace
tables - sqlQuery(channel,query,errors=TRUE)
tables
[1] [RODBC] ERROR: Could not SQLExecDirect
[2] S0022 1054 [unixODBC][MySQL][ODBC 3.51
Driver][mysqld-5.0.18-Debian_8-log]Unknown column 'plates' in 'field
list'
but if I use the correct column name, it returns an empty set
query - select plate from plates
tables - sqlQuery(channel,query,errors=TRUE)
tables
character(0)
odbcGetErrMsg(channel)
character(0)
although the same query issued with the mysql command line client (and
same username and password) gives 1202 rows.
And what happens if you issue the query using the isql commandline tool?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
Bug#354723: unixodbc: fails to retrieve data from ODBC connection
strace is useless for debugging a segfault. Please run your test script under gdb and forward the backtrace. http://wiki.debian.org/HowToGetABacktrace OK, thanks for the hint! I just wanted to install the build-deps for php5-odbc but then it wanted to deinstall a couple of things: stiller:~/tmp# LANG=en_EN apt-get build-dep php5-odbc Reading package lists... Done Building dependency tree... Done The following packages will be REMOVED: flex-old libdb3-dev libgnome-dev libmysqlclient12-dev flex-old and libmysqlclient12-dev were build-deps of unixodbc which I rebuilt earlier today. I guess that's the problem. So I would like to focus on RODBC: but if I use the correct column name, it returns an empty set query - select plate from plates tables - sqlQuery(channel,query,errors=TRUE) tables character(0) odbcGetErrMsg(channel) character(0) although the same query issued with the mysql command line client (and same username and password) gives 1202 rows. And what happens if you issue the query using the isql commandline tool? Then it also gives 1202 rows! So it seems to be a coincidence that both RODBC and php5-odbc are messed up on my system. I didn't know isql so far, although I was looking for something like this - it's great! I am just rebuilding R with the nostrip option because this is what I am really interested in. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
