google-code-export / pymssql

Automatically exported from code.google.com/p/pymssql
GNU Lesser General Public License v2.1
0 stars 0 forks source link

When pymssql.connect() with charset="cp949" on Windows, crash occurred. #50

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. To refer issue 48, build pymssql for windows.
2. try to connect mssql server as below script.
import pymssql
conn = pymssql.connect(server="192.168.123.xxx",
                user="id", password="pw", database="db", charset="cp949")
cur = conn.cursor()
cur.execute("select * from mytable")
for row in cur:
    print row

What is the expected output? What do you see instead?
It is expected that contents of table is printed.
But, Python crash occurred.

What version of the product are you using? On what operating system?
revision ab786211a2cc, Cython 0.14.1, Python 2.6.6, Windows 7

Please provide any additional information below.
Above code work well with pymssql 1.0.2.
I try to trace the crash point and find that crash occurred at 491 line in 
_mssql.pyx.

        # Set the login timeout
        dbsetlogintime(login_timeout)

        # Connect to the server
        self.dbproc = dbopen(login, server)  ### << crash here.

        # Frees the login record, can be called immediately after dbopen.
        dbloginfree(login)

Below error message is displayed with charset="utf-8".

+++ _mssql.MSSQLConnection.__cinit__()
+++ _mssql.MSSQLConnection.__init__()

*** err_handler(dbproc = 025D30D8, severity = 9,  dberr = 20017, oserr = 0, 
dberrstr = 'Unexpected EOF from the server',  oserrstr = 'No error'); 
DBDEAD(dbproc) = 0
*** previous max severity = 0

*** err_handler(dbproc = 025D30D8, severity = 9,  dberr = 20002, oserr = 0, 
dberrstr = 'Adaptive Server connection failed',  oserrstr = 'No error'); 
DBDEAD(dbproc) = 1
*** previous max severity = 9

+++ _mssql.MSSQLConnection.__init__() -> dbopen() returned NULL
+++ _mssql.MSSQLConnection.__dealloc__()
+++ _mssql.MSSQLConnection.close()
Traceback (most recent call last):
  File "testpymssql.py", line 3, in <module>
    user="id", password="pw", database="db", charset="utf-8")
  File "pymssql.pyx", line 516, in pymssql.connect (pymssql.c:6644)
    raise OperationalError(e[0])
pymssql.OperationalError: (20017, '\xc4DB-Lib error message 20017, severity 
9:\nUnexpected EOF from the server\nDB-Lib error message 20002, severity 
9:\nAdaptive Server connection failed\n')

Original issue reported on code.google.com by marun...@gmail.com on 27 Apr 2011 at 5:50

GoogleCodeExporter commented 9 years ago
> Below error message is displayed with charset="utf-8".

So it looks like even with the default charset, your connection params are 
still not correct.  Have you been able to get connected yet?

I know FreeTDS uses iconv when possible and has its own character encoding 
library when iconv is not available.  I wonder if that is part of the issue 
here.

Original comment by rsyr...@gmail.com on 7 May 2011 at 5:14

GoogleCodeExporter commented 9 years ago
This issue may occurred in FreeTDS.

FreeTDS is configured and compiled in below options.
./configure --prefix=/opt/freetds/freetds --enable-debug --enable-msdblib 
--enable-odbc-wide --with-tdsver=7.1 --disable-libiconv

Also, pymssql is compiled with '-g' option.

Below is captured by DrMingw.

python26.exe caused an Access Violation at location 74c9d193 in module 
msvcrt.dll Reading from location 00000961.

Registers:
eax=00000961 ebx=0027f180 ecx=0027f173 edx=7ffffffe esi=024cbf9d edi=00000961
eip=74c9d193 esp=0027eed8 ebp=0027f15c iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00210202

Call stack:
74C9D193  msvcrt.dll:74C9D193  _wtoi
74C9D220  msvcrt.dll:74C9D220  _vsnprintf_l
74C9D1C0  msvcrt.dll:74C9D1C0  vsnprintf
64E38551  libsybdb-5.dll:64E38551  vasprintf
64E2F696  libsybdb-5.dll:64E2F696  bcp_bind
64E023E6  libsybdb-5.dll:64E023E6  dbperror
64E0DDEC  libsybdb-5.dll:64E0DDEC  dblogin
64E1C192  libsybdb-5.dll:64E1C192  bcp_bind
64E2EAEE  libsybdb-5.dll:64E2EAEE  bcp_bind
64E1E712  libsybdb-5.dll:64E1E712  bcp_bind
64E1EA55  libsybdb-5.dll:64E1EA55  bcp_bind
64E17973  libsybdb-5.dll:64E17973  bcp_bind
64E19CB2  libsybdb-5.dll:64E19CB2  bcp_bind
64E19607  libsybdb-5.dll:64E19607  bcp_bind
64E1BA51  libsybdb-5.dll:64E1BA51  bcp_bind
64E1DA1D  libsybdb-5.dll:64E1DA1D  bcp_bind
64E1E4F7  libsybdb-5.dll:64E1E4F7  bcp_bind
64E0D381  libsybdb-5.dll:64E0D381  tdsdbopen
64F50E33  _mssql.pyd:64F50E33
1E009E44  python26.dll:1E009E44  PyNode_AddChild
1E012BE3  python26.dll:1E012BE3  PyEval_CallObjectWithKeywords
64F43A62  _mssql.pyd:64F43A62
1E01598F  python26.dll:1E01598F  PyDict_GetItem
1E012C68  python26.dll:1E012C68  PyCFunction_Call
1E0129FF  python26.dll:1E0129FF  PyObject_Call
1E1D2C30  python26.dll:1E1D2C30  PyInt_Type

Original comment by marun...@gmail.com on 11 May 2011 at 7:24

GoogleCodeExporter commented 9 years ago
I try to find crash's reason in the freetds library.
And, I find the reason.

When error message - Character set conversion is not available between client 
character set '%s' and server character set '%s' - is printed, two variable 
arguments of string type to be passed to vsaprintf function are missed and 
access violation occurred.

So, I fixed this problem temporary and the test script worked.
But, the result contained Korean characters is printed as empty character.
Again, I try to debug the freetds library.
And, I find that freetds's internal iconv don't supported "cp949" encodings.

Again, I try to compile freetds library linked against libiconv.

Original comment by marun...@gmail.com on 24 May 2011 at 10:29

GoogleCodeExporter commented 9 years ago

Original comment by rsyr...@gmail.com on 8 Mar 2012 at 3:26

GoogleCodeExporter commented 9 years ago
So is there any bug in pymssql or is this simply a bug in FreeTDS?

Original comment by msabr...@gmail.com on 7 Aug 2013 at 2:00

GoogleCodeExporter commented 9 years ago
This issue is a bug in freetds not pymssql.

Original comment by marun...@gmail.com on 9 Aug 2013 at 10:51

GoogleCodeExporter commented 9 years ago
IMHO this issue is superseded by issue54.

Original comment by cra...@gmail.com on 21 Aug 2013 at 6:05

GoogleCodeExporter commented 9 years ago
Closing since this is a FreeTDS problem and issue54 appears to be a workaround

Original comment by msabr...@gmail.com on 19 Sep 2013 at 5:47