processlist  usually is able to make a connection even in these cases, and can provide useful information about the current number of connections and their status. 

•Run the command mysqladmin -i 5 status  or mysqladmin -i 5 -r status  in a separate window to produce statistics while running other queries. 

•Try the following: 

1. Start mysqld  from gdb  (or another debugger). See Section 5.9, “Debugging MySQL” . 

2. Run your test scripts. 

3. Print the backtrace and the local variables at the three lowest levels. In gdb , you can do this with the following commands when mysqld  has crashed inside gdb : 

backtrace info local up info local up info local 

With gdb , you can also examine which threads exist with info threads  and switch to a specific thread with thread N , where N  is the thread ID. 

•Try to simulate your application with a Perl script to force MySQL to exit or misbehave. 

•Send a normal bug report. See Section 1.6, “How to Report Bugs or Problems” . Be even more detailed than usual. Because MySQL works for many people, the crash might result from something that exists only on your computer (for example, an error that is related to your particular system libraries). 

•If you have a problem with tables containing dynamic-length rows and you are using only VARCHAR columns (not BLOB  or TEXT  columns), you can try to change all VARCHAR  to CHAR  with ALTER TABLE . This forces MySQL to use fixed-size rows. Fixed-size rows take a little extra space, but are much more tolerant to corruption. 

The current dynamic row code has been in use for several years with very few problems, but dynamic- length rows are by nature more prone to errors, so it may be a good idea to try this strategy to see whether it helps. 

•Consider the possibility of hardware faults when diagnosing problems. Defective hardware can be the cause of data corruption. Pay particular attention to your memory and disk subsystems when troubleshooting hardware. 

## B.3.3.4 How MySQL Handles a Full Disk 

This section describes how MySQL responds to disk-full errors (such as “no space left on device” ), and to quota-exceeded errors (such as “write failed”  or “user block limit reached” ). 

This section is relevant for writes to MyISAM  tables. It also applies for writes to binary log files and binary log index file, except that references to “row”  and “record”  should be understood to mean “event.” 

When a disk-full condition occurs, MySQL does the following: 

•It checks once every minute to see whether there is enough space to write the current row. If there is enough space, it continues as if nothing had happened. 

•Every 10 minutes it writes an entry to the log file, warning about the disk-full condition. 

