'python.exe has stopped working ' when testting database connection with pymssql

[GoogleCodeExporter]

Install mysql5.5 and sqlserver2012 on the same server(same pc, 
windowsserver2008r2).
mysql5.5 using 3306 port
sqlserver2012  using 1433 port

Case 1: pymssql connect the sqlserver2012 with 1433 port
result: OK

Case 2: pymssql connect the sqlserver2012 with 1432 or 3307 port(no used port)
result: NG , and pymssql return Exception

Case 3: pymssql connect the sqlserver2012 with 3306 port(using by mysql5.5)
result: NG , pymssql return nothing and python shot down: "python.exe has 
stopped working "

When Case3 error happen, no Exception can be catch and python.exe just dead ... 
...
Anyone has idea of how to handle the Case3 error ?

PS: I tryyed to connect 3306 port with [sqlserver managment] and error 
message(something like coding bug? not the standard sql message) is different 
whit connectting no used port.

Original issue reported on code.google.com by dean.c...@ofusion.net on 11 Jan 2013 at 4:11

[GoogleCodeExporter]

So to be clear, are you saying that you'd like pymssql to not hang and raise 
some kind of exception (instead of hanging) when it is pointed at a port that 
is running something that is not SQL Server?

Original comment by msabr...@gmail.com on 11 Jan 2013 at 7:26

[GoogleCodeExporter]

My bet is this is a FreeTDS thing and not so much in pymssql's camp.  I'd 
recommend using one of FreeTDS's command line tools to hit a mysql port and see 
if it has the same problem.

Original comment by randy.sy...@lev12.com on 12 Jan 2013 at 12:59

[GoogleCodeExporter]

to Comment 1 :
Yes, that is what i want
I'd like to create a "db connection test" page in my webset and just like 
sqlserver management or other query brower. If connection failed ,it need to 
return a message to user. So i use [try...expect... ] to catch these Exception 
and alert they to user.
When i test this function , accidentally pointed at a port running mysql, 
python.exe dead and i can't catch the Exception. 

to Comment 2 :
Thanks for your attention!

Original comment by dean.c...@ofusion.net on 14 Jan 2013 at 1:58

[GoogleCodeExporter]

I can reproduce this on Linux.

Trying to connect to a remote MySQL server (3306/tcp) generates a Segmentation 
fault.

Strangely, trying to connect to SSH (22/tcp) blocks and eventually times out 
but it doesn't crash the interpreter.

Will try to debug and report to freetds (hopefully with a patch).

Original comment by cra...@gmail.com on 20 Aug 2013 at 11:48

[GoogleCodeExporter]

Current findings:

$ TDVER=7.1 gdb --args tsql -H <MySQL server IP addr.> -p 3306
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from tsql...done.
(gdb) run
Starting program: tsql -H 172.17.2.15 -p 3306
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
locale is "en_US.UTF-8"
locale charset is "UTF-8"
using default charset "UTF-8"

Program received signal SIGSEGV, Segmentation fault.
tds_read_packet (tds=tds@entry=0x63e3e0) at net.c:584
584             memcpy(tds->in_buf, header, 8);

(gdb) bt
#0  tds_read_packet (tds=tds@entry=0x63e3e0) at net.c:584
#1  0x000000000040f651 in tds8_do_login (connection=0x63e860, tds=0x63e3e0) at 
login.c:1024
#2  tds_connect (tds=tds@entry=0x63e3e0, connection=connection@entry=0x63e860, 
p_oserr=p_oserr@entry=0x7fffffffddec) at login.c:456
#3  0x000000000040ffa6 in tds_connect_and_login (tds=tds@entry=0x63e3e0, 
connection=connection@entry=0x63e860) at login.c:506
#4  0x0000000000403858 in main (argc=<optimized out>, argv=<optimized out>) at 
tsql.c:771

(gdb) print tds->in_buf
$1 = (unsigned char *) 0x0

(gdb) print header
$1 = "?\000\000\000\n5.0"

Original comment by cra...@gmail.com on 20 Aug 2013 at 8:52

[GoogleCodeExporter]

I think it' safe to close this issue now because, as suspected, this is a 
FreeTDS issue.

This is fixed in FreeTDS master development branch and discussion is starting 
about if/how to fix this on the 0.91 bug-fixes-only branch.

The FreeDTS mailing list thread tracking this is this one: 
http://lists.ibiblio.org/pipermail/freetds/2013q3/028461.html

Original comment by cra...@gmail.com on 21 Aug 2013 at 2:57

[GoogleCodeExporter]

Original comment by rsyr...@gmail.com on 21 Aug 2013 at 5:19

• Changed state: Invalid

[GoogleCodeExporter]

Thank you, Ramiro!

Original comment by msabr...@gmail.com on 26 Aug 2013 at 9:09