turbodbc icon indicating copy to clipboard operation
turbodbc copied to clipboard

mariadb odbc connector falls into infinite loop

Open muskirac opened this issue 7 years ago • 5 comments

I'm not sure whether this bug is in turbodbc or mariadb connector layer.

We are using MariaDB slaves in our infrastructure. On OSX we have installed mariadb-connector-odbc using brew (versions mariadb-connector-c 3.0.3 and mariadb-connector-odbc 3.0.2 got installed). Then we set our DSN entries accordingly (pointing Driver to libmaodbc.dylib, and identifying DSN as MaSQL).

The following Python code enters into an infinite loop, due to the fact that cursor.next() does not consume the final record after fetching everything:

from turbodbc import connect connection = connect(dsn="MaSQL") cursor = connection.cursor() cursor.execute("select * from sometable limit 1")

In [3]: cursor.rowcount Out[3]: 1

In [4]: cursor.next() Out[4]: [1]

In [5]: cursor.next() Out[5]: [1]

In [6]: cursor.fetchall() Out[6]: ---- does not finish, fills up the whole memory and swap area

###################

When we switch to generic MySQL driver downloaded from https://dev.mysql.com/downloads/connector/odbc the problem goes away.

In [3]: cursor.rowcount Out[3]: 1

In [4]: cursor.next() Out[4]: [1]

In [5]: cursor.next()

StopIteration Traceback (most recent call last) in () ----> 1 cursor.next()

~/anaconda3/lib/python3.6/site-packages/turbodbc/cursor.py in next(self) 79 element = self.fetchone() 80 if element is None: ---> 81 raise StopIteration 82 else: 83 return element

In [6]: cursor.fetchall() Out[6]: []

muskirac avatar Mar 28 '18 07:03 muskirac

Hi Mustafa! My first impulse is to say that this is a MariaDB connector issue, seeing that the standard MySQL connector and a couple of other drivers work as expected. I could imagine that the MariaDB connector does not properly use the SQL_ATTR_ROWS_FETCHED_PTR ODBC variable. In any case, the MariaDB connector does not seem to be as drop-inny as advertised ;-).

Could you provide an ODBC trace for your issue (or at least the first two fetch commands, seeing that the ODBC trace should grow infinitely long in an infinite loop)?

MathMagique avatar Mar 28 '18 08:03 MathMagique

@muskirac Do you have an update for me (or a linked issue)?

MathMagique avatar Apr 10 '18 18:04 MathMagique

Here is the output of the trace while the fetchall is in infinite loop (with MariaDB Driver): loop_trace.txt

The infinite loop fills in the log quickly with millions of the following:

[ODBC][1931][1523425922.670344][SQLFetchScroll.c][353] Exit:[SQL_NO_DATA] [ODBC][1931][1523425922.670468][SQLFetchScroll.c][159] Entry: Statement = 0x7fa5f69c4800 Fetch Orentation = 1 Fetch Offset = 0

And here is the one that uses the proper MySQL driver: success_trace.txt

In this case, fetching after the last row is consumed, it could move to FreeHandle stage:

[ODBC][1922][1523425884.465900][SQLFetchScroll.c][353] Exit:[SQL_NO_DATA] [ODBC][1922][1523425884.470153][SQLFreeHandle.c][381] Entry: Handle Type = 3 Input Handle = 0x7facde830800

Please advise if we should report the bug against the driver.

Thanks.

muskirac avatar Apr 11 '18 06:04 muskirac

just wanted to mention that I just came across this as well! Unfortunate, and I looked at the mariadb odbc code to see if I could work through it relatively quick, and it is just a bit beyond me, so it would probably take more time than I'm willing to put into it now to trace it through.

I also didn't see any mention of this bug in their bug tracker, so may be good to put on their radar (I can follow up later)

drin avatar Jul 10 '18 16:07 drin

Issue still occurring with connector 3.0.8

benjaminrigaud avatar Apr 17 '19 13:04 benjaminrigaud