Pyodbc + Pyplot + ipython/jupyter notebook + macOS causes kernel death on pyodbc.connect()

[ArcoSeal]

Environment

To diagnose, we usually need to know the following, including version numbers. On Windows, be
sure to specify 32-bit Python or 64-bit:

• Python: 3.7.2 (running via ipython kernel)
• pyodbc: 4.0.25
• OS: macOS 10.14.3 / Darwin 18.2.0
• DB: MS SQL Server (2013?)
• driver: FreeTDS

Issue

This is weirdly specific, but here goes:

If I import pyplot from matplotlib before I run pyodbc.connect() in a Jupyter notebook on macOS/Darwin, the kernel dies. However, if I change the order I'm OK. Examples:

FAILS (kernel dies)

from matplotlib import pyplot as plt # the use (or not) of the "as plt" alias doesn't make a difference
import pyodbc

SERVER_CONNECTION_STRING = 'DRIVER=FreeTDS;SERVER=<server>;UID=<user>;PWD=<pwd>;port=1433;TDS_Version=8.0;UseNTLMv2=Yes;ApplicationIntent=ReadOnly'

pyodbc.connect(SERVER_CONNECTION_STRING)

OK

import pyodbc
pyodbc.connect(SERVER_CONNECTION_STRING)

from matplotlib import pyplot as plt

There's no error thrown, no traceback and stepping through via pdb doesn't show anything. It doesn't seem to affect running code at the command line or in an interactive terminal.

I'm wondering if there's some conflict with the pyplot.connect() function? Can't figure out why that would be though. Or maybe something to do with objects at the C level?

I've tried it on a colleague's system (Anaconda on Windows) and it works fine.

I'm still investigating but unsure how to proceed so any suggestions would be welcome!

(Appreciate this could also be Jupyter or Matplotlib's fault, but figured this was the best place to start)

[v-chojas]

Could you post an ODBC trace of both the successful and failure cases?

[ArcoSeal]

odbctrace_fail.txt
odbctrace_success.txt

[v-chojas]

What version of unixODBC are you using (odbcinst -j to determine)?
Could you try using the Microsoft ODBC Driver 17 for SQL Server?

[v-chojas]

The traces do not show anything suspicious, the only difference is that the failure one has what appears to be the end of a different connection at the beginning, and then it gets cut off after a call to SQLGetTypeInfo() which hasn't yet returned.

[ArcoSeal]

unixODBC is 2.3.7

So far haven't been successful using the Microsoft drivers (either 17 or 13) on OS X / *nix, not sure if that's due to how our MS SQL Server is set up or if I just have the connection string wrong (this is why we use FreeTDS on non-Windows computers). Will keep trying!

[mkleehammer]

I was not able to reproduce this with either the FreeTDS 1.00.109 driver or the MS 17.0.3 (just released) driver with the same Python and pyodbc versions. The matplotlib version was 3.0.2.

I added the import to the top of pyodbc's tests3/sqlservertests.py file and it runs fine with both drivers.

This really has the hallmarks of a memory corruption error. Matplotlib has 11 libraries of its own, plus I think it pulls in numpy. Those are very widely used libraries though.

Can you try the same test I did, just to get us closer to the same test? Add from matplotlib import pyplot as plt as the first import in the sqlservertests.py file and run it?

[mkleehammer]

Can you also test with 4.0.26 which I just released? There was a Unicode string error that could cause a crash. I don't think it was related, but it is worth a shot.

[ArcoSeal]

I don't think it was related, but it is worth a shot.

Famous last words! Turns out this does fix the issue on my system. I went back-and-forth between 4.0.25 & 4.0.26 and various sources to confirm.

I'd be interested to know the root cause. Do you think it was a direct result of the Unicode issue #506 , or if it was memory related (as mentioned above) have the updates magically fixed things by causing them to end up somewhere else in memory? The latter is beyond my ken, I'm afraid!

[mkleehammer]

I'd guess #506. Sorry for the trouble with that.

[ArcoSeal]

Thanks for the assistance @mkleehammer & @v-chojas !