Re: ERROR 2013 at line 1960: Lost connection to MySQL server during query on Linux SMP

[Jim Faucette]

Van wrote:
> 
> Actually, my apologies.  I don't recall submitting the table structure.
> Thanks for the continued interest in this.
> bash$ mysql cdarchive -e 'describe cd'
> +------------+------------+------+-----+---------+-------+
> | Field      | Type       | Null | Key | Default | Extra |
> +------------+------------+------+-----+---------+-------+
> | cdname     | char(8)    |      | MUL |         |       |
> | datemod    | char(8)    |      |     |         |       |
> | timemod    | char(8)    |      |     |         |       |
> | size       | bigint(21) |      |     | 0       |       |
> | user       | char(8)    |      |     |         |       |
> | groupowned | char(10)   |      |     |         |       |
> | perms      | char(4)    |      |     |         |       |
> | fullname   | char(255)  |      | MUL |         |       |
> | filename   | char(255)  |      |     |         |       |
> +------------+------------+------+-----+---------+-------+
> 
> Yes, it does.  I don't actually need the bigint (could be int,
> actually), but the nature of this database is to assist in filesystem
> library management once Linux files grow beyond 2 Gbytes natively.

We had a similar problem (and changed to an int) on FreeBSD. When a
BIGINT value exceeds some point mysqld core dumps on:
mysql somedb < somedumpfile

This consistantly happens with 0xFFFFFFFFFFFFFFFF. Here's the gdb
output:

Program terminated with signal 8, Floating point exception.
#0  0x80c6691 in __fixunsdfdi ()
(gdb) where
#0  0x80c6691 in __fixunsdfdi ()
#1  0x8063c57 in Field_longlong::store ()
#2  0x804c2ed in Item_real::save_in_field ()
#3  0x80838a3 in fill_record ()
#4  0x8090a35 in mysql_insert ()
#5  0x807460e in mysql_execute_command ()
#6  0x80756b5 in mysql_parse ()
#7  0x8073860 in do_command ()
#8  0x80733d3 in handle_one_connection ()
#9  0x2810e636 in _thread_start ()

See if there's a mysqld.core file in /usr/local/var (or where ever your
DB files are located).

  jim...