| Bug #5607 | seqfault in client.c:cli_read_rows() (query cache related?) | ||
|---|---|---|---|
| Submitted: | 16 Sep 2004 11:38 | Modified: | 11 Jan 2005 10:56 |
| Reporter: | Sergey Kostyliov | Email Updates: | |
| Status: | Can't repeat | Impact on me: | |
| Category: | MySQL Server | Severity: | S3 (Non-critical) |
| Version: | 4.1.4 (compiled from sources) | OS: | Linux (Linux (Gentoo v2004.2)) |
| Assigned to: | CPU Architecture: | Any | |
[11 Jan 2005 10:56]
Aleksey Kishkin
Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.mysql.com/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to 'Open'. Thank you for your interest in MySQL.
[1 Jul 2005 21:24]
sujay koduri
I also got the similar problem with mysql_stmt_prepare function. (Modifying the query as mentioned helps many time :)..Including the backtrace from gdb below. #0 0x42074d7e in malloc_consolidate () from /lib/tls/libc.so.6 #1 0x420743c9 in _int_malloc () from /lib/tls/libc.so.6 #2 0x4207378d in malloc () from /lib/tls/libc.so.6 #3 0x4002f81a in my_malloc () from /usr/lib/libmysqlclient.so.14 #4 0x40032476 in alloc_root () from /usr/lib/libmysqlclient.so.14 #5 0x400504b0 in cli_read_rows () from /usr/lib/libmysqlclient.so.14 #6 0x4002a77a in cli_read_prepare_result () from /usr/lib/libmysqlclient.so.14 #7 0x4002a9d3 in mysql_stmt_prepare () from /usr/lib/libmysqlclient.so.14 #8 0x0804a5b1 in prepare_stmt_MySQL () at data_access_layer.c:577 But all the time it seg faulted, I found some memory issues, which after fixing them, everything worked fine. But I think this weird behaviour also need to be looked into. (Not seg faulting when the query is changed a bit)
Description: The query already cached by mysql query cache will lead to client api segfault after some time (~1-2 days). Query is executed against table which have never changed. Segfalut will disappear if I change the text of the query a bit (e.g. "select * from replication_table where type='DIFF' or shared=1;" leads to segfault, but "select * from replication_table where type='DIFF' or shared= 1;" does not.) ?r if I modify the table itself (e.g "ALTER TABLE replication_table ENGENE=MyISAM"). If I understand mysql query cache nature correctly, once the query had cached it's result has never changed from MySQL C API angle of view, so it looks like there are two separate problems first is: data in query cache had changed somehow, second: thats manifested via the bug in MySQL C API. But of course it is just a theory and I could be wrong. How to repeat: I'm sorry, but I couldn't provide reproduceable test case for the time being. Only backtrace: Program received signal SIGSEGV, Segmentation fault. 0x4027855c in memcpy () from /lib/libc.so.6 (gdb) bt #0 0x4027855c in memcpy () from /lib/libc.so.6 #1 0x40097624 in cli_read_rows (mysql=0x8078980, mysql_fields=0x0, fields=7) at client.c:1300 #2 0x4009a0e7 in cli_read_query_result (mysql=0x8078980) at client.c:2359 #3 0x4009a4fe in mysql_real_query (mysql=0x8078980, query=0x807dfa8 "select * from replication_table where type='DIFF' or shared=1", length=61) at client.c:2413 #4 0x08051f13 in mysql_real_query_for_lazy(char const*, int) ( buf=0x807dfa8 "select * from replication_table where type='DIFF' or shared=1", length=61) at mysql.cc:1579 #5 0x080528e9 in com_go (buffer=0x8078d88, line=0x0) at mysql.cc:1801 #6 0x0805104f in add_line (buffer=@0x8078d88, line=0x80f9f70 "select * from replication_table where type='DIFF' or shared=1;", in_string=0xbffff8af "", ml_comment=0xbffff8a7) at mysql.cc:1136 #7 0x080509e4 in read_lines (execute_commands=true) at mysql.cc:986 #8 0x0804fc66 in main (argc=7, argv=0x807a518) at mysql.cc:441 (gdb)