[egenix-users] mx.odbc segmentation fault on fetching string
M.-A. Lemburg
mal at egenix.com
Tue Jun 3 19:20:26 CEST 2008
On 2008-06-03 17:43, M.-A. Lemburg wrote:
> For the other list members and the archives ...
>
> After some private discussion, it turned out that using iODBC instead
> of unixODBC solved the problem.
>
> However, we were not able to reproduce the problem on our machines, so
> in case you run into similar problems, please let us know.
>
> FWIW, the only difference between our setup and Wouter's was the version
> of unixODBC being used - they had 2.2.11 installed, we compile mxODBC
> against the more recent 2.2.12.
FWIW: We tried 2.2.11 as well and could still not reproduce the
problem.
Perhaps Debian builds unixODBC using the "REAL 64bit" option that
unixODBC provides.
This would lead to a segfault when used with the mx.ODBC.unixODBC
package we provide, since in "REAL 64bit" mode, unixODBC doesn't
follow the MS ODBC standard. It uses the native 64-bit support
and bit lengths on Linux instead.
> Note that when using FreeTDS, it is often better to try using iODBC
> as well. Our internal tests often show a much better performance of the
> FreeTDS driver with iODBC than unixODBC, with much better being up to
> 2-3x faster depending on the usage pattern, so it's well worth a try.
>
> Thanks.
>
> On 2008-06-03 11:56, M.-A. Lemburg wrote:
>> We ran our test suite using our release candidate 2 of mxODBC 3.0.2
>> against FreeTDS 0.82 with unixODBC and iODBC, with SQL Server 2000 and
>> SQL Server 2005, but could not reproduce the problem you are seeing.
>>
>> We've uploaded the RC2 to our server. Could you try with that
>> version ?
>>
>> http://downloads.egenix.com/python/egenix-mxodbc-3.0.2_rc2.linux-x86_64-py2.5_ucs4.prebuilt.zip
>>
>>
>> Thanks,
>>
>> On 2008-06-03 11:35, M.-A. Lemburg wrote:
>>> On 2008-06-03 11:20, M.-A. Lemburg wrote:
>>>> On 2008-06-03 02:49, Wouter van Atteveldt wrote:
>>>>> Dear list,
>>>>>
>>>>> I am evaluating mx.odbc for connecting to a MS SQL server from my
>>>>> Linux machine using freetds 0.82. I can connect and query using
>>>>> isql without problem, but I get a segmentation fault if I fetch
>>>>> using the mx.odbc interface.
>>>>
>>>> isql uses a different, all-strings based access method to the ODBC
>>>> driver, so it can really only be used to verify that a connection
>>>> works, not much more.
>>>>
>>>> mxODBC always tries to use the best possible access method to
>>>> avoid frequent copying and conversion of the data.
>>>>
>>>>> wva at amcat:~/tmp$ isql -v AmcatDB <UID> <PWD>
>>>>> +---------------------------------------+
>>>>> | Connected!
>>>>> [...]
>>>>> +---------------------------------------+
>>>>> SQL> select top 1 projectid, name from projects
>>>>> [...]
>>>>> | 1 | test
>>>>> [...]
>>>>> SQLRowCount returns 1
>>>>> 1 rows fetched
>>>>>
>>>>> wva at amcat:~/tmp$ python testodbc.py
>>>>> connected to Microsoft SQL Server 08.00.2039
>>>>> Executed, fetching...
>>>>> [(1,)]
>>>>> Executed, fetching...
>>>>> Segmentation fault
>>>>
>>>> Could you send us the core dump of this segfault ? It is most likely
>>>> a problem in the new FreeTDS ODBC driver. FreeTDS 0.63 works just fine
>>>> on x64 machines.
>>>
>>> ... and so does version 0.64. We're testing 0.82 now. Did you compile
>>> FreeTDS against unixODBC or iODBC ?
>>>
>>>> It would be great if you could also provide the table
>>>> definition and example data that allows us reproducing the
>>>> error on our servers.
>>>>
>>>>> wva at amcat:~/tmp$ cat testodbc.py
>>>>> import mx.ODBC
>>>>> db = mx.ODBC.unixODBC.connect("AmcatDB", "<UID>", "<PWD>")
>>>>> print "connected to %s %s" % (db.dbms_name, db.dbms_version)
>>>>> c = db.cursor()
>>>>> c.executedirect("select top 1 projectid from projects")
>>>>> print "Executed, fetching..."
>>>>> print c.fetchall()
>>>>> c.executedirect("select top 1 projectid, name from projects")
>>>>> print "Executed, fetching..."
>>>>>
>>>>> print c.fetchall()wva at amcat:~/tmp$ uname -a
>>>>> Linux amcat 2.6.18-6-amd64 #1 SMP Sun Feb 10 17:50:19 UTC 2008 x86_64
>>>>> GNU/Linux
>>>>> wva at amcat:~/tmp$ python -c "import
>>>>> sys;print(sys.maxunicode<66000)and'UCS2'or'UCS4'"
>>>>> UCS4
>>>>>
>>>>> As you can see, it returns the MS SQL version number so it has some
>>>>> contact with the remote db. I installed using
>>>>> egenix-mxodbc-3.0.1.linux-x86_64-py2.5_ucs4.prebuilt.zip, which I
>>>>> think should be OK as x86_64 == AMD64 (right?). projected is int,
>>>>> name is a varchar(255) column, and the table should have a couple
>>>>> hundred entries at most.
>>>>>
>>>>> The relevant etc files:
>>>>>
>>>>> wva at amcat:~/tmp$ tail -4 /usr/local/freetds/etc/freetds.conf
>>>>> [amcatdb]
>>>>> host = localhost
>>>>> port = 1433
>>>>> tds version = 8.0
>>>>> wva at amcat:~/tmp$ cat /etc/odbc.ini
>>>>> [AmcatDB]
>>>>> Driver = FreeTDS
>>>>> Description = amcatdb MS SQL Database
>>>>> Trace = No
>>>>> Servername = amcatdb
>>>>> Database = anoko
>>>>> wva at amcat:~/tmp$ cat /etc/odbcinst.ini
>>>>> [FreeTDS]
>>>>> Description = v0.63 with protocol v8.0
>>>>> Driver = /usr/local/freetds/lib/libtdsodbc.so
>>>>> UsageCount = 1
>>>>>
>>>>> Note that I am using an SSH tunnel to connect to the sql server,
>>>>> hence the localhost. This does not give trouble using either tsql,
>>>>> isql, or python-sybase (on a previous install), so I am not
>>>>> expecting this to be the cause of the problem.
>>>>>
>>>>> Any help greatly appreciated!
>>>>
>>>> Thanks,
>>>
>>
>
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jun 03 2008)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
2008-07-07: EuroPython 2008, Vilnius, Lithuania 33 days to go
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
More information about the egenix-users
mailing list