Bug #13894 Server crashes on update of CSV table
Submitted: 10 Oct 2005 11:06 Modified: 9 Nov 2005 3:13
Reporter: Petr Chardin Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server Severity:S3 (Non-critical)
Version:5.1-bk, 5.0 (?) OS:Linux (Suse Linux 9.3)
Assigned to: Petr Chardin CPU Architecture:Any

[10 Oct 2005 11:06] Petr Chardin
Description:
the following sequence of statements crashes the server:

DROP TABLE IF EXISTS test_update;
CREATE TABLE test_update ( val integer ) ENGINE = CSV;
INSERT INTO test_update VALUES (5);
INSERT INTO test_update VALUES (10);
INSERT INTO test_update VALUES (11);
INSERT INTO test_update VALUES (10);
UPDATE  test_update SET val=6 WHERE val=10;
DROP TABLE test_update;

I've checked this only with 5.1 but 5.0 should be affected as well (as there is almost no difference in CSV code between 5.0 and 5.1). 

The crash happens in ha_tina::rnd_end(). 
This routine removes "holes" in the file, which occured during updates/deletes. The information about the holes is stored in the chain of records. Looks like this cleanup doesn't work properly when there is more then one link in the chain.

How to repeat:
See sequence of statements above
[10 Oct 2005 12:29] MySQL Verification Team
Verified with 5.0:

051010  9:26:15 [Note] /home/miguel/dbs/5.0/libexec/mysqld: ready for connections.
Version: '5.0.15-rc-debug'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution
[New Thread 1132456880 (LWP 6710)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1132456880 (LWP 6710)]
0x40254a43 in memmove () from /lib/tls/libc.so.6
(gdb) bt full
#0  0x40254a43 in memmove () from /lib/tls/libc.so.6
No symbol table info available.
#1  0x083486ce in ha_tina::rnd_end (this=0x8e79f08) at ha_tina.cc:805
        ptr = (tina_set *) 0x8e7b024
        length = 27
        _db_func_ = 0x85aede9 "handler.h"
        _db_file_ = 0x85aef46 "ha_rnd_end"
        _db_level_ = 135571703
        _db_framep_ = (char **) 0x437fd808
#2  0x0814a957 in handler::ha_rnd_end (this=0x8e79f08) at handler.h:612
        _db_func_ = 0x437fd824 "@Ø\177CHØ\177C\237ã)\b\b\237ç\b\004"
        _db_file_ = 0x2f4 <Address 0x2f4 out of bounds>
        _db_level_ = 137659616
        _db_framep_ = (char **) 0x437fd828
#3  0x0814a750 in handler::ha_index_or_rnd_end (this=0x8e79f08) at handler.h:617
No locals.
#4  0x0829e39f in end_read_record (info=0x437fd9a0) at records.cc:155
No locals.
#5  0x082572dd in mysql_update (thd=0x8e385a0, table_list=0x8e63808, fields=@0x8e38884, values=@0x8e38a4c, conds=0x8e63b98, order_num=0, 
    order=0x0, limit=18446744073709551613, handle_duplicates=DUP_ERROR, ignore=false) at sql_update.cc:463
        using_limit = false
<cut>
[5 Nov 2005 12:16] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/31981
[8 Nov 2005 0:35] Petr Chardin
Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at
    http://www.mysql.com/doc/en/Installing_source_tree.html

Additional info:

pushed into 4.1.16 and merged to 5.0.16
[9 Nov 2005 3:13] Paul DuBois
Noted in 4.1.16, 5.0.16 changelogs.