| Bug #9692 | my_strcasecmp_8bit recieves "Address out of bounds" from get_charset_number | ||
|---|---|---|---|
| Submitted: | 6 Apr 2005 18:43 | Modified: | 30 May 2013 12:42 |
| Reporter: | Matthew Boehm | Email Updates: | |
| Status: | Duplicate | Impact on me: | |
| Category: | Connector / ODBC | Severity: | S1 (Critical) |
| Version: | 3.51.12, 3.51.11 | OS: | Solaris (Solaris, RedHat 9.0 (2.4.20)) |
| Assigned to: | CPU Architecture: | Any | |
[8 Apr 2005 3:14]
MySQL Verification Team
Testing on Slackware 10.0 with a sleep connection through 6 hours and an mysql_ping() performed, the client application not crashed. Could you please attach your my.cnf file ? Thanks in advance.
[13 Apr 2005 15:38]
Matthew Boehm
This morning when I attempted to repeat this bug, I was presented with a new error: Server Error: Can't initialize character set latin1 (path: /usr/share/mysql/charsets/) The latin1 file has global read permissions as does the path to it.
[19 Apr 2005 15:45]
Philippe Jalaber
I am using unixODBC 2.2.11, MyODBC 3.51.11 and MySQL 4.1.11. ODBC function SQLConnect returns the following error when called multiple times (about 20 times) in a C program: #Character set 'latin1' is not a compiled character set and is not specified in the '/usr/share/mysql/charsets/Index.xml' file Sometimes my program seg faults in function my_strcasecmp_8bit in libmysqlclient_r.so library.
[26 Apr 2005 19:08]
Saju Paul
Workaround: (if you are not interested in the latin1 charset) edit /usr/share/mysql/charset/Index.xml. Delete all lines defined for latin1.
[3 May 2005 4:38]
Matthew Boehm
Now I'm getting this on a brand new app I just created. What is the deal? What do you guys need to help fix this? This is obviously a bug.
#0 0x404fa1c9 in my_strcasecmp_8bit (cs=0x40516980, s=0x68632f73 <Address 0x68632f73 out of bounds>, t=0x81151a8 "latin1")
at ctype-simple.c:199
199 while (map[(uchar) *s] == map[(uchar) *t++])
(gdb) bt
#0 0x404fa1c9 in my_strcasecmp_8bit (cs=0x40516980, s=0x68632f73 <Address 0x68632f73 out of bounds>, t=0x81151a8 "latin1")
at ctype-simple.c:199
#1 0x404ef842 in get_charset_number (charset_name=0x81151a8 "latin1", cs_flags=32) at charset.c:444
#2 0x404efc91 in get_charset_by_csname (cs_name=0x81151a8 "latin1", cs_flags=32, flags=16) at charset.c:551
#3 0x40505e9b in mysql_real_connect (mysql=0x404c89e0, host=0x40d39300 "285.88.55.44", user=0x40d39340 "myuser",
passwd=0x40d39380 "myuser", db=0x40d393c0 "mypass", port=3306, unix_socket=0x0, client_flag=0) at client.c:1882
[3 May 2005 4:41]
Matthew Boehm
argh. I can't continue developing my app cause everytime I load the mysql module the app crashes. let me know what you need. I'll send anything.
[3 May 2005 19:06]
Matthew Boehm
Here is some more info. Why do some of these cs[] blocks have OOB errors?
(gdb) print cs
$1 = (CHARSET_INFO *) 0x403939a0
(gdb) print cs[0]
$2 = {number = 8, primary_number = 0, binary_number = 0, state = 801, csname = 0x812eb28 "", name = 0x812eb30 "", comment = 0x812eb08 "",
tailoring = 0x0, ctype = 0x403926e0 "", to_lower = 0x40392800 "", to_upper = 0x40392900 "", sort_order = 0x40392a00 "",
contractions = 0x0, sort_order_big = 0x0, tab_to_uni = 0x40392b00, tab_from_uni = 0x0, state_map = 0x812b598 "", ident_map = 0x812b698 "",
strxfrm_multiply = 1, mbminlen = 1, mbmaxlen = 1, min_sort_char = 0, max_sort_char = 255, cset = 0x40393920, coll = 0x40393c80}
(gdb) print cs[0]->csname
$3 = 0x812eb28 ""
(gdb) print cs[1]->csname
$4 = 0x4037c630 "U\211åWV\203ì\020\213u\f\213U$\213M(\212E\024\210E÷\212E\030\210Eö\212E\034\210Eõ\213E\020\001ð\211Eð\211Uì\213E \215<\020;uðtp9útl\212E÷8\006u\f\215F\001;Eðt\004\211ÆëG\212Eö8\006u\017Æ\002"
(gdb) print cs[2]->csname
$5 = 0x0
(gdb) print cs[3]->csname
$6 = 0x0
(gdb) print cs[4]->csname
$7 = 0xf <Address 0xf out of bounds>
(gdb) print cs[5]->csname
$8 = 0x1 <Address 0x1 out of bounds>
(gdb) print cs[6]->csname
$9 = 0x0
(gdb) print cs[7]->csname
$10 = 0x4037bddc "U\211åWVS\203ì<è"
(gdb) print cs[8]->csname
$11 = 0x0
(gdb) print cs[9]->csname
$12 = 0x1010101 <Address 0x1010101 out of bounds>
(gdb) print cs[10]->csname
$13 = 0x0
[13 May 2005 10:41]
Sergei Golubchik
This apparently looks like a memory corruption. The crash occurs when corrupted data are accessed, and it does not tell us much. Try to find when this corruption happens (this is not easy :(, you can use e.g. valgrind, or watchpoints in gdb)
[1 Jun 2005 13:02]
Philippe Jalaber
I wrote a simple test program that uses unixODBC 2.2.11 to connect to a MySQL 4.1.12 database with MyODBC 3.51.11 connector. The program runs on linux Mandrake 10.1 with 2.4.27 kernel. unixODBC, MySQL and MyODBC have been compiled from tarballs with gcc 3.4.1.
The program launches 10 threads, each thread creates 6 connections to the database and close them. If you allocate the SQLHENV in the main program and use it in each thread in order to allocate each SQLHDBC, everything is OK. Now if you allocate a new SQLHENV in each thread, ODBC reports the following error when creating the 5-6 last connections:
Character set 'latin1' is not a compiled character set and is not specified in the '/usr/share/mysql/charsets/Index.xml' file
(1) HYT00:2019:[unixODBC][MySQL][ODBC 3.51 Driver]Can't initialize character set latin1 (path: /usr/share/mysql/charsets/)
Sometimes the program seg faults.
I also tested the same program with a PostgreSQL database, it works fine. So unixODBC does not seem to be the problem.
here is the test program (the program is linked with tls pthread library)
to compile it: gcc test.c -o test -lodbc -lpthread
Hope it helps.
#include <stdlib.h>
#include <stdio.h>
#include <sql.h>
#include <sqlext.h>
#include <pthread.h>
static void odbc_sqlerror(SQLSMALLINT type, SQLHANDLE handle){
SQLCHAR state[7];
SQLCHAR text[1024];
SQLSMALLINT len;
int i=0;
SQLINTEGER native;
while( SQL_SUCCEEDED(SQLGetDiagRec(type, handle, ++i, state, &native, text, sizeof(text), &len))) {
fprintf(stderr, "(%d) %s:%ld:%s\n", i, state, native, text);
}
}
static SQLHDBC new_hdbc(const char *db, SQLHENV henv){
SQLRETURN retcode;
SQLHDBC hdbc;
retcode = SQLAllocHandle(SQL_HANDLE_DBC, henv, &hdbc);
if ((retcode != SQL_SUCCESS) && (retcode != SQL_SUCCESS_WITH_INFO)) {
odbc_sqlerror(SQL_HANDLE_DBC, hdbc);
return NULL;
}
retcode = SQLConnect(hdbc, (char*)db, SQL_NTS,
NULL, 0, NULL, 0);
if ((retcode != SQL_SUCCESS) && (retcode != SQL_SUCCESS_WITH_INFO)) {
odbc_sqlerror(SQL_HANDLE_DBC, hdbc);
SQLFreeHandle(SQL_HANDLE_DBC, hdbc);
return NULL;
}
return hdbc;
}
static void free_hdbc(SQLHDBC hdbc){
int retcode;
retcode = SQLDisconnect(hdbc);
if ((retcode != SQL_SUCCESS) && (retcode != SQL_SUCCESS_WITH_INFO)) {
odbc_sqlerror(SQL_HANDLE_DBC, hdbc);
}
SQLFreeHandle(SQL_HANDLE_DBC, hdbc);
if ((retcode != SQL_SUCCESS) && (retcode != SQL_SUCCESS_WITH_INFO)) {
odbc_sqlerror(SQL_HANDLE_DBC, hdbc);
}
}
static SQLHENV new_henv(void){
SQLHENV henv;
SQLRETURN retcode;
retcode = SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &henv);
if ((retcode != SQL_SUCCESS) && (retcode != SQL_SUCCESS_WITH_INFO)) {
odbc_sqlerror(SQL_HANDLE_ENV, henv);
return NULL;
}
SQLSetEnvAttr(henv, SQL_ATTR_ODBC_VERSION, (SQLPOINTER)SQL_OV_ODBC3, 0);
return henv;
}
static void free_henv(SQLHDBC henv){
int retcode;
retcode = SQLFreeHandle(SQL_HANDLE_ENV, henv);
if ((retcode != SQL_SUCCESS) && (retcode != SQL_SUCCESS_WITH_INFO)) {
odbc_sqlerror(SQL_HANDLE_ENV, henv);
}
}
void *routine(void *arg){
#define NB_CNX 6
SQLHENV henv;
SQLHDBC hdbc[NB_CNX];
int i;
int j;
int release_henv = 0;
henv = (SQLHENV)arg;
if (henv == NULL) {
release_henv = 1;
if ((henv = new_henv()) == NULL) {
return NULL;
}
}
for (i = 0; i < NB_CNX; i++) {
printf("Thread %x: opening connection %d\n", pthread_self(), i);
if ((hdbc[i] = new_hdbc("DB", henv)) == NULL) {
return NULL;
}
}
for (i = 0; i < NB_CNX; i++) {
printf("Thread %x: closing connection %d\n", pthread_self(), i);
free_hdbc(hdbc[i]);
}
if (release_henv) {
free_henv(henv);
}
return NULL;
}
int main(){
#define NB_THREAD 10
pthread_t thread[NB_THREAD];
int i;
struct timeval tv;
SQLHENV henv;
/* setting this variable to 1 will force the program to use
only one SQLHENV allocated in the main program. however if set to 0
the program will allocate an SQLHENV in each thread
*/
int one_henv = 0;
if (one_henv) {
if ((henv = new_henv()) == NULL) {
return 0;
}
}
for (i = 0; i < NB_THREAD; i++) {
pthread_create(&thread[i], NULL, routine, (one_henv) ? henv : NULL);
}
for (i = 0; i < NB_THREAD; i++) {
pthread_join(thread[i], NULL);
}
if (one_henv) {
free_henv(henv);
}
}
[13 Jun 2005 23: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".
[24 Sep 2005 21:40]
Mike
This bug is also blocking me from implementing a commercial server using MySQL. Using C++ with unixODBC 2.2.11, MySQL Server 4.1.14 and MyODBC 3.51.10 on SuSE linux 9.0. It happens every time if I make a connection, then disconnect, then make a connection again. Each time through the connection process, I'm allocating a new ENV handle, new connection handles, etc. Valgrind says my_strcasecmp_8bit is reading memory that was freed during SQLDisconnect: Invalid read of size 1 at 0x1BDF5EA3: my_strcasecmp_8bit (in /usr/local/lib/libmyodbc3-3.51.10.so) by 0x1BDEF375: get_charset_number (in /usr/local/lib/libmyodbc3-3.51.10.so) by 0x1BDEF618: get_charset_by_csname (in /usr/local/lib/libmyodbc3-3.51.10.so) by 0x1BE044DC: mysql_real_connect (in /usr/local/lib/libmyodbc3-3.51.10.so) by 0x1BDD4DCF: SQLConnect (in /usr/local/lib/libmyodbc3-3.51.10.so) by 0x1BA36814: SQLConnect (SQLConnect.c:3819) by 0x804C106: CDBConnection::Connect(char const*, char const*, char const*) (DBConnection.cpp:79) by 0x804BCA0: main (Main.cpp:31) Address 0x1BD64CE8 is 3888 bytes inside a block of size 4088 free'd at 0x1B90254E: free (vg_replace_malloc.c:235) by 0x1BDEE87D: my_once_free (in /usr/local/lib/libmyodbc3-3.51.10.so) by 0x1BDE9A83: my_end (in /usr/local/lib/libmyodbc3-3.51.10.so) by 0x1BDD82A1: myodbc_end (in /usr/local/lib/libmyodbc3-3.51.10.so) by 0x1BDDAEA8: my_SQLFreeEnv (in /usr/local/lib/libmyodbc3-3.51.10.so) by 0x1BDDAF13: SQLFreeHandle (in /usr/local/lib/libmyodbc3-3.51.10.so) by 0x1BA34E3F: ??? (SQLConnect.c:2321) by 0x1BA3506C: __disconnect_part_four (SQLConnect.c:2490) by 0x1BA351EC: __disconnect_part_three (SQLConnect.c:2586) by 0x1BA38D8B: SQLDisconnect (SQLDisconnect.c:331) by 0x804C6E6: CDBConnection::Disconnect() (DBConnection.cpp:212) by 0x804BC42: main (Main.cpp:25) Can someone please at least post a workaround so we can continue to develop our apps? The steps to hit this are very fundamental and repeatable and the consequences are very bad. Let me know if more information is needed to debug this. Thanks. -Mike
[2 Oct 2005 10:45]
Valeriy Kravchuk
This bug report contains information about 3 (different) problems, reported by Matthew Boehm, Philippe Jalaber, and Mike. I am closing it as "No feedback" (because there is no feedback from the original bug reporter for a long time). I also think they have nothing to do with server itself, but are related to the ODBC driver. Philippe and Mike: please, open new bug reports, if you still have the same problems with MySQL 4.1.14 and MyODBC 3.51.11.
[21 Jan 2007 9:25]
David Gornshtein
We have exactly the same BUG on Sparc Solaris 8 and with MyODBC 3.51.12. we have commercial (MySQL Enterprise 5.0.xx, actually this happens with all version of 5.0.xx) and looks like MyODBC bug rather then MySQL server itself. I am going to open also commercial support call since we are paid customer there is application failure stack from the core file: f86440e4 my_strcasecmp_8bit (10547430, 20, f8693400, f8786ebc, f87872b8, f8786ecc) + c f8640818 get_charset_by_csname (10547430, 20, 10, ffffffff, 10547430, 7) + 10 f865b19c mysql_real_connect (13a08960, 13601148, 1052a1f8, 10547400, 1058a800, cea) + 864 f86241a4 my_SQLDriverConnectTry (13a08958, 1119c450, 700, 0, 15d036f0, 10ff9360) + 98 f86245e0 my_SQLDriverConnect (13a08958, 0, f7f05200, 29, f7f04144, 800) + 3c4 f8624808 SQLDriverConnect (13a08958, 0, f7f05200, 29, f7f04144, 800) + 30 fb21f78c SQLDriverConnect (117c5630, 0, f7f05200, 29, f7f04144, 800) + e94 fd19e6a8 __1cEodbcIotl_connGrlogon6Mpkcki_i_ (13deeb40, f7f05200, 0, 0, 44, 0) + 568 fc01883c __1cDbswXMySQdDLDBServerConnection2t5B6Mkpkn0ANMySQdDLDBServer_rknGString_888_v_ (13deeb28, 1, 113980 , 13deeb40, fc1b2eec, 132600) + 1bc fc018640 __1cDbswNMySQdDLDBServerQgetNewConnection6MrknGString_444_pn0AXMySQdDLDBServerConnection__ (51f55a0, 113980, 11e0a8, 136e60, 132600, 13deeb28) + 20 fc00de5c __1cDbswIDBServerJdbConnect6Mrki_pn0BKConnection__ (132600, 0, 20, 136e60, 0, 0) + cdc fc00c218 __1cDbswIDBServerHconnect6Mri_pn0BKConnection__ (1, 51f57a0, fc1436ac, fc1b6be0, fc1be324, 51f55a0) + 78 fc00cc24 __1cDbswIDBServerNactivateDBMsg6Mrn0AFDBMsg__v_ (51f55a0, efdda90, 1, fc143c7d, fc1b6bf4, fc1be338) + 484 fc00d128 __1cDbswIDBServerOprocessMessage6Mrn0AHAutoPtr4n0AFDBMsg____v_ (51f55a0, f7f05c5c, efdda90, 0, fc1ab7 54, 0) + 8 fee545d8 __1cDbswSAutoPtrMultiTaskAO4n0AFDBMsg__PprocessMessage16Mrpn0B__v_ (51f55a0, f7f05cc4, efdda90, fc00d 120, efdda90, fc1b7168) + 18 fee588b0 __1cDbswLMultiTaskAO4Cpn0AFDBMsg__GWorkerHexecute6M_v_ (51f6060, fc019ac0, fc1b7168, fee545c0, fc1b71 68, efdda90) + 50 fbf376b4 __1cDbswRstaticTaskExecute6Fpv_1_ (51f6060, fbf376a0, 51f6060, 1, fee58860, fef0cea8) + 14 fe15b01c _thread_start (e5290, 0, 0, 0, 0, 0) + 40
[21 Jan 2007 9:45]
Valeriy Kravchuk
I am re-opening this bug report as it seems repeatable with latest MyODBC 3.51.12 on Solaris.
[21 Jan 2007 9:54]
Valeriy Kravchuk
Please, send the results of: find / -name "libmysqlclient*" -print 2>/dev/null echo $LD_LIBRARY_PATH and inform about the exact unixODBC version used.
[21 Jan 2007 13:34]
David Gornshtein
1. We have actually two instances of mysql 5.0.20 on two different machines connected via mysql replication, so application connects to both instances BUT, this is really does not matter same machine or not same machine. Machine 1 Machine 2 MySQL 1 <-> MySQL 2 Application 1 Application 2 Application 1 connected to both MySQL1 and MySQL2 Application 2 connected to both MySQL1 and MySQL2 However, again, let's look at this model in simpler context - we have MyODBC client, DON'T linked with server, always connecting to the server via tcp/ip .odbc.ini attached. 2. we are NOT using libmysqlclient.so.14, since the protocol has been changed and therefore libmysqlclient.so.14 can not be used to connect to MySQL 5.0.xx - as you can see /usr/local/lib/libmysqlclient.so.14 is symbolic link to /usr/local/lib/libmysqlclient_r.so and /usr/local/lib/libmysqlclient_r.so is really libmysqlclient_r.so.15.0.0 pdadmin@wcs01:/home/pdadmin> nm /usr/local/lib/libmysqlclient_r.so | grep FILE | grep libmysqlclient_r [1] | 0 | 0 | FILE | LOCL | 0 | ABS | .libs/libmysqlclient_r.so.15.0.0 This symbolic link has been created to fake perl DBI. In addition to that, /usr/local/lib/libmyodbc3-3.51.12.so is not linked with /usr/local/lib/libmysqlclient_r.so at all ... I think it's linked statically. 3. I have sent pmap - map of the process in memory - you can see that only libmyodbc3-3.51.12.so really used there and libmysqlclient_r has not been used. I guess that libmyodbc3-3.51.12.so is statically linked. 4. Unless you have certain problem clarification, with an appropriate test cases, that will show what is the problem and how will it be solved by upgrade, I am NOT going to upgrade working customer production - it's critical 24x7 production - HLR proxy of tier 2 cellular operator environment. Regards, David Gornshtein. Oracle Certified DBA Solaris Certified System Administrator Phone: +972 (9) 9517771 / ext 0221 Fax: +972 (9) 9517772 Cellular: +972 (54) 4636694 Email (office): davidg@convergin.com -----Original Message----- From: Valeriy Kravchuk [MySQL Support] [mailto:issue-13941@support.mysql.com] Sent: Sunday, January 21, 2007 1:22 PM To: David Gornshtein Subject: [#13941] Re: application crash with core inside MyODBC 3.51.xx Hi David, > 1. core created by application working via MySQL 5.0.20 > > but it's core from the application side - > > working on another machine ! OK. Are you sure it is MySQL 5.0.20 that is used on that another machine, where MyODBC is installed? I already know from your next email that it is 32-bit. But according to other your results I am not sure about 5.0.20. What exact MySQL binaries did you install on that client machine? > 2. my.cnf attached Thank you. Is it from that another machine, where MyODBC is installed? If no, please, send one (if any) from it. Just for completeness. > pdadmin@wcs01:/home/pdadmin>ls -ltra > /usr/local/lib/libmysqlclient_r.so > > -rw-r--r-- 1 root other 443412 Dec 6 05:15 /usr/local/lib/libmysqlclient_r.so > > pdadmin@wcs01:/home/pdadmin>ls -ltra > /usr/local/lib/libmysqlclient.so.14 > > lrwxrwxrwx 1 root other 34 Dec 6 05:15 /usr/local/lib/libmysqlclient.so.14 -> /usr/local/lib/libmysqlclient_r.so According to the following, these results are from the same mahcine where your application works. Great. But(!) note that you have *.so.14 is used. It is from MySQL 4.0.x days! And it may surely not work properly with character sets, I think. You need libmysqlclient.so.15. > pdadmin@wcs01:/home/pdadmin>pmap 11088 | grep -i odbc > F8600000 480K read/exec /usr/local/lib/libmyodbc3-3.51.12.so > F8686000 1032K read/write/exec /usr/local/lib/libmyodbc3-3.51.12.so > FB200000 504K read/exec /usr/lib/libodbc.so.1.0.0 > FB28C000 88K read/write/exec /usr/lib/libodbc.so.1.0.0 > FBCD0000 88K read/exec /usr/lib/libodbcinst.so.1.0.0 > FBCF4000 24K read/write/exec /usr/lib/libodbcinst.so.1.0.0 Yes, we clearly see that version 3.51.12 is used, and: > pdadmin@wcs01:/home/pdadmin>ldd /usr/local/lib/libmyodbc3-3.51.12.so > librt.so.1 => /usr/lib/librt.so.1 > libcrypt_i.so.1 => /usr/lib/libcrypt_i.so.1 > libgen.so.1 => /usr/lib/libgen.so.1 > libsocket.so.1 => /usr/lib/libsocket.so.1 > libnsl.so.1 => /usr/lib/libnsl.so.1 > libm.so.1 => /usr/lib/libm.so.1 > libltdl.so.3 => /usr/local/lib/libltdl.so.3 > libdl.so.1 => /usr/lib/libdl.so.1 > libodbcinst.so.1 => /usr/lib/libodbcinst.so.1 > libc.so.1 => /usr/lib/libc.so.1 > libaio.so.1 => /usr/lib/libaio.so.1 > libmp.so.2 => /usr/lib/libmp.so.2 > libgcc_s.so.1 => /usr/local/gcc/gcc3.1/lib/libgcc_s.so.1 > libCrun.so.1 => > /usr/phonedo/ver/current/lib/solaris_release/libCrun.so.1 > libCstd.so.1 => /usr/phonedo/ver/current/lib/solaris_release/libCstd.so.1 > libthread.so.1 => /usr/lib/libthread.so.1 > libucb.so.1 => /usr/ucblib/libucb.so.1 > libresolv.so.2 => /usr/lib/libresolv.so.2 > libelf.so.1 => /usr/lib/libelf.so.1 > /usr/platform/SUNW,Netra-240/lib/libc_psr.so.1 it seems it is not linked with libmysqlclient.so.* at all (or I missed something). > pdadmin@wcs01:phonedo/data>echo $LD_LIBRARY_PATH Let me list all the directries one per row: /usr/phonedo/ver/current/lib/solaris_release ... /usr/local/mysql++/mysql++-1.7.9/lib /usr/local/mysql-3.24.49/lib/mysql /usr/local/gcc/gcc3.1/lib /usr/local/unixodbc/unixodbc-2.2.1/lib ... /usr/local/lib /usr/local/ActiveTcl/lib So, before /usr/local/lib (where libmysqlclient.so.14 is located) you have: /usr/local/mysql++/mysql++-1.7.9/lib /usr/local/mysql-3.24.49/lib/mysql I do not think these directories are still needed in LD_LIBRARY_PATH at all (although it is not a problem for this issue). > pdadmin@wcs01:phonedo/data>isql --version unixODBC 2.2.10
[22 Jan 2007 19:04]
Bogdan Degtyariov
The test case below (actually the same program listed as the comment) works well if use thread-safe driver binary (libmyodbc3_r-3.51.12.so) instead of non-thread-safe one (libmyodbc3-3.51.12.so). As non-thread-safe version will be eliminated from the distribution I would recommend using the thread-safe versions of MyODBC driver in non-multithread applications.
[22 Jan 2007 19:05]
Bogdan Degtyariov
test case
Attachment: test9692.c (text/x-csrc), 4.19 KiB.
[22 Jan 2007 19:08]
Bogdan Degtyariov
One more note regarding this bug report: all MyODBC drivers are being linked statically against libmysqlclient.a/libmysqlclient_r.a libs. So, "ldd libmyodbc3-3.51.12.so" will not show any dependences on mysql client library.
[22 Feb 2007 0: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".
[30 May 2013 12:42]
Bogdan Degtyariov
Duplicate of bug #15547
Description: When custom app (linked with libmysqlclient) opens a connection, and that connection times out (after several hours of no traffic) a subsequent mysql_ping will crash the app. "res_config_mysql.so" is the name of the mysql module in my app. IP addresses and passwords have been changed to protect the innocent. #0 0x404fffa6 in my_strcasecmp_8bit (cs=0x4051ad80, s=0x1 <Address 0x1 out of bounds>, t=0x8134038 "latin1") at ctype-simple.c:158 #1 0x404f565a in get_charset_number (charset_name=0x8134038 "latin1", cs_flags=32) at charset.c:444 #2 0x404f5aa9 in get_charset_by_csname (cs_name=0x8134038 "latin1", cs_flags=32, flags=16) at charset.c:551 #3 0x4050bb28 in mysql_real_connect (mysql=0x40e1c3fc, host=0x813a600 "64.88.47.55", user=0x813a668 "astdev", passwd=0x813a698 "devast", db=0x813a6c8 "ast", port=3306, unix_socket=0x0, client_flag=2147525261) at client.c:1854 #4 0x4050c694 in mysql_reconnect (mysql=0x404cea00) at client.c:2154 #5 0x405093ea in cli_advanced_command (mysql=0x404cea00, command=COM_PING, header=0x0, header_length=0, arg=0x0, arg_length=0, skip_check=0 '\0') at client.c:674 #6 0x404e4726 in mysql_ping (mysql=0x404cea00) at libmysql.c:1378 #7 0x404cc08d in key () from /usr/lib/ast/modules/res_config_mysql.so How to repeat: Amazingly, this is very repeatable. I've repeated this crash every morning so far. Open a connection with mysql_real_connect(). Wait about 5 hours (I'm not sure of the exact time frame, but I know that 3 hours isn't enough and that overnight is plenty). Call mysql_ping() on the 5+ hr connection. *crash* Suggested fix: My cheezy-i'm-not-a-C-guru-programmer fix would be to add a check in my_strcasecmp_8bit to see if "s" is valid before I run any comparisons on it. However, I'm sure that it should never reach this state so I'm guessing there is a better solution.