| Bug #85684 | Segmentation fault in mysql_get_character_set_info | ||
|---|---|---|---|
| Submitted: | 29 Mar 2017 13:47 | Modified: | 30 Apr 2017 2:00 |
| Reporter: | Vladimir V | Email Updates: | |
| Status: | No Feedback | Impact on me: | |
| Category: | Connector / ODBC | Severity: | S2 (Serious) |
| Version: | 5.3.7 | OS: | Debian (Jessie) |
| Assigned to: | Assigned Account | CPU Architecture: | Any |
| Tags: | connector, MySQL, ODBC | ||
[29 Mar 2017 13:47]
Vladimir V
[30 Mar 2017 10:51]
Bogdan Degtyariov
Hi Vladimir, Thanks for your interest in MySQL Connector/ODBC. Unfortunately, your report does not contain enough information to be able to identify the real problem. Running 10-15 queries per second is not a very conclusive way to repeat a bug. There are systems running ODBC queries at the rate of hundreds QPS for days and weeks, but no such crashes are reported from them. I need to request more relevant details from you: - Do you have the full stack trace? - What sort of application is using ODBC? Is it something that you or your company develop? - Is the application single or multi-threaded? - Are Connection (HDBC*) or Statement (HSTMT*) handles shared between threads? Please consider the possibility of the race conditions if the use of the connection or statement is not mutex-protected - What is the version of the ODBC Driver Manager being used? - Please provide the connection parameters (DSN or Connection string) The user/password info should be asterisk-ed for the security reasons. - Are there any other relevant details that might be of importance? I am looking forward to receiving your feedback and have all my questions answered. Thanks. P.S: The severity level of the problem you reported does not match S1 definition: S1 Represents a complete loss of service, a significant functionality is missing, a system that hangs indefinitely; and there is no available workaround. Your system experiences interruption of service, which is serious, but not S1. Therefore the severity is set to S2
[30 Mar 2017 15:22]
Vladimir V
Hi, Bogdan! > - Do you have the full stack trace? No. > - What sort of application is using ODBC? Python script with asyncio features: * Python 3.6.0 * aioodbc 0.0.3 (pyodbc) > - Is the application single or multi-threaded? Asyncio coroutines, one connection to coroutine. > - What is the version of the ODBC Driver Manager being used? unixodbc-2.3.1-3 > - Please provide the connection parameters (DSN or Connection string) [dsn] Driver=mysql_odbc Server=localhost Socket=/run/mysqld/mysqld.sock Port=3306 Database=*** User=*** Password=*** Option=1 ReadOnly=No UNICODE=UTF-8
[31 Mar 2017 2:00]
Bogdan Degtyariov
Hi Vladimir, Thank you for your reply. I noticed a few things that might help to resolve or at least identify the issue. Your DSN contains key-value pairs that are invalid for Connector/ODBC because it won't be able to interpret them: ReadOnly=No UNICODE=UTF-8 Please try removing ReadOnly=No. Also, I can guess that UNICODE=UTF-8 is an attempt to specify the character set for the ODBC connection. The correct way of doing this would be (notice UTF8 is without "-") CHARSET=UTF8 And the last, but not least, if the desired charset is UTF8 you might try using the ANSI version of the driver (libmyodbc5a.so) instead of UNICODE (libmyodbc5w.so). The ANSI version is guaranteed to handle UTF8 data because UTF8 does not have characters containing \0 byte that could be interpreted as string termination. In fact, we even recommend doing so because there would be no string conversion involved. Please let me know if changing the DSN options and the driver library had any effect. Thanks.
[1 May 2017 1:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".
