FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

2011/7/12 Marc DellaVolpe <marc.dellavolpe AT gmail.com>:
> I have run into a strange issue with SQLAlchemy/PyODBC/FreeTDS/unixODBC/
> SQL Server 2005 that I was hoping someone can shed some light on.
>
> I have two SQL Server 2005 instances with the same table created on
> each.  The contents of the tables differ.  The servers appear to be
> identical to each other in configuration except that the builds of SQL
> Server are different.  When fetching rows on  from the newer build,
> the fetch succeeds as normal.  When fetching rows from the older
> build, pyodbc.so segfaults.  The same query/fetch works fine in tsql/
> isql from the command line which leads me to believe that it is not a
> FreeTDS issue.  I am not sure where the issue lies but I figured I
> would try with PyODBC and FreeTDS.  Is it possible that there is some
> bad data in the table to cause this?  I have attached a dump from each
> session.  You will notice a truncation error message at the end of the
> segfaulting log, The longest row in that table is length 509 / data
> length 1018 so I am not sure about the context of this error message.
>
> As a temporary work around, I have changed the column to varchar(max)
> which works.  As a last resort, I can apply the updates to the
> segfaulting database but I would greatly appreciate more insight into
> this issue before I do.
>
> The working instance:
>
> Microsoft SQL Server 2005 - 9.00.1406.00 (Intel X86)
>       Mar  3 2007 18:40:02
>       Copyright (c) 1988-2005 Microsoft Corporation
>       Developer Edition on Windows NT 5.2 (Build 3790: Service Pack 2)
>
> Dump of session - http://pastebin.com/8NcDkvQy
>
> The segfaulting instance:
>
> Microsoft SQL Server 2005 - 9.00.1399.06 (Intel X86)
>       Oct 14 2005 00:33:37
>       Copyright (c) 1988-2005 Microsoft Corporation
>       Workgroup Edition on Windows NT 5.2 (Build 3790: Service Pack 2)
>
> Dump of session - http://pastebin.com/vAtPVZvD
>
> Thank You,
> - Marc

Which PyODBC/unixODBC version are you using?
I bet is a mismatch between SQLWCHAR and Py_UNICODE type.

Looking at not-working log mssql returns 0x49c == 1180. PyODBC try to
read 1024 bytes and get 1022 bytes which left 158 bytes to read then
PyODBC try to read 160 bytes (158 + 2 terminator). All is correct and
should work but then pyodbc cores... Allocations seem good and should
not cause problems however if Python is using Py_UNICODE_SIZE == 4
should even convert string from UCS-2 to UCS-4 (I didn't test this).

Which operating system/version are you using ?

bye
  freddy77