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

[16 Sep 2004 11:38] Sergey Kostyliov
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 
"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 
[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

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)