Bug #5607 seqfault in client.c:cli_read_rows() (query cache related?)

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)

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.

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)