MySQL Bugs: #37815: mysql crashes with "stack smashing detected" after a large table repair

Bug #37815	mysql crashes with "stack smashing detected" after a large table repair
Submitted:	2 Jul 2008 18:05	Modified:	6 Aug 2008 12:55
Reporter:	ivan beschastnikh	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Server: Command-line Clients	Severity:	S3 (Non-critical)
Version:	5.0.51a	OS:	Linux (Ubuntu 8.04, 2.6.24-19-generic)
Assigned to:		CPU Architecture:	Any
Tags:	stack smashing detected \ mysql terminated

Description:
I'm running a MySQL server with a data_dir pointing to an NFS mount exported from a NAS device. I ran into performance issues when attempting to build an index on a single field of a large table (1.5 TB). So instead, I used a method described here:

http://peter-zaitsev.livejournal.com/11772.html

i.e. I created an empty table with identical layout except that it already has an index defined on the field I would like indexed. Then I moved the MYD file to correspond to the new table, and then ran:

repair NO_WRITE_TO_BINLOG table table_tmp QUICK;

The repair took 2 days 4 hours, and looks like it succeeded (I don't know how to verify). However, the mysql session crashed (log of backtrace\memory map attached in next reply) with "*** stack smashing detected ***: mysql terminated". I found the following post describing a similar-sounding problem, but wasn't able to find any bug reports on the issue:

http://forums.mysql.com/read.php?12,186014,186014

The table I'm trying to index has two fields and 118272519 rows:
 
mysql> desc table_tmp;
+-------+------------+------+-----+---------+-------+
| Field | Type               | Null | Key | Default | Extra |
+-------+------------+------+-----+---------+-------+
| revid | int(11)           | YES  | MUL | NULL    |       |
| txt     | mediumtext | YES  |          | NULL    |       |
+-------+------------+------+-----+---------+-------+

How to repeat:
Perhaps the problem occurs with a large table size. Not sure.

repair output, backtrace and memory map at time of crash

Attachment: log.txt (text/plain), 4.72 KiB.

To clarify the repair output, my sort buffer sizes are:
myisam_sort_buffer_size 8388608
sort_buffer_size        1048575992

Also, during repair, the created TMD file ran out of space and the repair stalled for about an hour before more space was made available.

looks like a client crash, not server bug.  duplicate of bug #33976 perhaps ?

Yes, its a client crash. The category listing doesn't list 'Client' as a choice, but it would be appropriate to classify it differently. Yes, it looks related to bug <a href="http://bugs.mysql.com/bug.php?id=33841">bug #33841</a>, perhaps the different arch is causing a stack smashing segfault instead of an error in strcpy.

I will set it as duplicate from bug #33841.

This is already fixed in our source releases and will be available with our next 5.0 release. It already should be available in our version 5.1.26-rc.