Administration-Related Issues 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. •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. 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. 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. 5303