you should report the bug to <a href="mailto:mysql@lists.mysql.com">mysql@lists.mysql.com</a>. 
Links to mail archives are available at the online <a href="http://www.mysql.com/doc.html"><strong>MySQL</strong> 
documentation page</a>. </p>

<p>If you get corrupted tables or if <code>mysqld</code> always fails after some update 
commands, you can test if this bug is reproducible by doing the following: 

<ul>
  <li>Stop the mysqld daemon (with <code>mysqladmin shutdown</code>) </li>
  <li>Check all tables with <code>myisamchk -s database/*.MYI</code>. Repair any wrong tables 
    with <code>myisamchk -r database/table.MYI</code>. </li>
  <li>Start <code>mysqld</code> with <code>--log-update</code> </li>
  <li>When you have got a crashed table, stop the <code>mysqld server</code>. </li>
  <li>Restore the backup. </li>
  <li>Restart the <code>mysqld</code> server <strong>without</strong> <code>--log-update</code> 
  </li>
  <li>Re-execute the commands with <code>mysql &lt; update-log</code>. The update log is saved 
    in the <strong>MySQL</strong> database directory with the name <code>your-hostname.#</code>. 
  </li>
  <li>If the tables are now again corrupted, you have found reproducible bug in the <code>ISAM</code> 
    code! FTP the tables and the update log to <a href="ftp://www.mysql.com/pub/mysql/secret">ftp://www.mysql.com/pub/mysql/secret</a> 
    and we will fix this as soon as possible! </li>
</ul>

<p>The command <code>mysqladmin debug</code> will dump some information about locks in 
use, used memory and query usage to the mysql log file. This may help solve some problems. 
This command also provides some useful information even if you haven't compiled <strong>MySQL</strong> 
for debugging! </p>

<p>If the problem is that some tables are getting slower and slower you should try to 
optimize the table with <code>OPTIMIZE TABLE</code> or <code>myisamchk</code>. See section 
<a href="manual_Maintenance.html#Maintenance">13 Maintaining a MySQL installation</a>. You 
should also check the slow queries with <code>EXPLAIN</code>. </p>

<p>You should also read the OS-specific section in this manual for problems that may be 
unique to your environment. See section <a
href="manual_Installing.html#Source_install_system_issues">4.11 System-specific issues</a>. 
</p>

<p><a name="IDX839"></a><a name="IDX840"></a><a name="IDX841"></a><a name="IDX842"></a>If 
you are using the Perl <code>DBI</code> interface, you can turn on debugging information 
by using the <code>trace</code> method or by setting the <code>DBI_TRACE</code> 
environment variable. See section <a href="manual_Clients.html#Perl_DBI_Class">20.5.2 The <code>DBI</code> 
interface</a>. </p>

<h2><a href="manual_toc.html#Debugging_client" name="Debugging_client">G.2 Debugging a 
MySQL client</a></h2>

<p>To be able to debug a <strong>MySQL</strong> client with the integrated debug package, 
you should configure <strong>MySQL</strong> with <code>--with-debug</code>. See section <a
href="manual_Installing.html#configure_options">4.7.3 Typical <code>configure</code> 
options</a>. </p>

<p><a name="IDX843"></a><a name="IDX844"></a>Before running a client, you should set the <code>MYSQL_DEBUG</code> 
environment variable: </p>

<pre>shell&gt; MYSQL_DEBUG=d:t:O,/tmp/client.trace
shell&gt; export MYSQL_DEBUG
</pre>

<p>This causes clients to generate a trace file in <tt>`/tmp/client.trace'</tt>. </p>

<p>If you have problems with your own client code, you should attempt to connect to the 
server and run your query using a client that is known to work. Do this by running <code>mysql</code> 
in debugging mode (assuming you have compiled <strong>MySQL</strong> with debugging on): </p>

<pre>shell&gt; mysql --debug=d:t:O,/tmp/client.trace
</pre>

<p>This will provide useful information in case you mail a bug report. See section <a
href="manual_Questions.html#Bug_reports">2.3 How to report bugs or problems</a>. </p>

<p>If your client crashes at some 'legal' looking code, you should check that your <tt>`mysql.h'</tt> 
include file matches your mysql library file. A very common mistake is to use an old <tt>`mysql.h'</tt> 
file from an old <strong>MySQL</strong> installation with new <strong>MySQL</strong> 
library. </p>

<h2><a href="manual_toc.html#RTS-threads" name="RTS-threads">G.3 Comments about RTS 
threads</a></h2>

<p>I have tried to use the RTS thread packages with <strong>MySQL</strong> but stumbled on 
the following problems: </p>

<p>They use old version of a lot of POSIX calls and it is very tedious to make wrappers 
for all functions. I am inclined to think that it would be easier to change the thread 
libraries to the newest POSIX specification. </p>

<p>Some wrappers are already written. See <tt>`mysys/my_pthread.c'</tt> for more info. </p>

<p>At least the following should be changed: </p>

<p><code>pthread_get_specific</code> should use one argument. <code>sigwait</code> should 
take two arguments. A lot of functions (at least <code>pthread_cond_wait</code>, <code>pthread_cond_timedwait</code>) 
should return the error code on error. Now they return -1 and set <code>errno</code>. </p>

<p>Another problem is that user-level threads use the <code>ALRM</code> signal and this 
aborts a lot of functions (<code>read</code>, <code>write</code>, <code>open</code>...). <strong>MySQL</strong> 
should do a retry on interrupt on all of these but it is not that easy to verify it. </p>

<p>The biggest unsolved problem is the following: </p>

<p>To get thread-level alarms I changed <tt>`mysys/thr_alarm.c'</tt> to wait between 
alarms with <code>pthread_cond_timedwait()</code>, but this aborts with error <code>EINTR</code>. 
I tried to debug the thread library as to why this happens, but couldn't find any easy 
solution. </p>

<p>If someone wants to try <strong>MySQL</strong> with RTS threads I suggest the 
following: 

<ul>
  <li>Change functions <strong>MySQL</strong> uses from the thread library to POSIX. This 
    shouldn't take that long. </li>
  <li>Compile all libraries with the <code>-DHAVE_rts_threads</code>. </li>
  <li>Compile <code>thr_alarm</code>. </li>
  <li>If there are some small differences in the implementation, they may be fixed by changing 
    <tt>`my_pthread.h'</tt> and <tt>`my_pthread.c'</tt>. </li>
  <li>Run <code>thr_alarm</code>. If it runs without any ``warning'', ``error'' or aborted 
    messages, you are on the right track. Here follows a successful run on Solaris: <pre>Main thread: 1
Tread 0 (5) started
Thread: 5  Waiting
process_alarm
Tread 1 (6) started
Thread: 6  Waiting
process_alarm
process_alarm
thread_alarm
Thread: 6  Slept for 1 (1) sec
Thread: 6  Waiting
process_alarm
process_alarm
thread_alarm
Thread: 6  Slept for 2 (2) sec
Thread: 6  Simulation of no alarm needed
Thread: 6  Slept for 0 (3) sec
Thread: 6  Waiting
process_alarm
process_alarm
thread_alarm
Thread: 6  Slept for 4 (4) sec
Thread: 6  Waiting
process_alarm
thread_alarm
Thread: 5  Slept for 10 (10) sec
Thread: 5  Waiting
process_alarm
process_alarm
thread_alarm
Thread: 6  Slept for 5 (5) sec
Thread: 6  Waiting
process_alarm
process_alarm

...
thread_alarm
Thread: 5  Slept for 0 (1) sec
end
</pre>
  </li>
</ul>

<h2><a href="manual_toc.html#Thread_packages" name="Thread_packages">G.4 Differences 
between different thread packages</a></h2>

<p><strong>MySQL</strong> is very dependent on the thread package used. So when choosing a 
good platform for <strong>MySQL</strong>, the thread package is very important. </p>

<p>There are at least three types of thread packages: 

<ul>
  <li>User threads in a single process. Thread switching is managed with alarms and the 
    threads library manages all non-thread-safe functions with locks. Read, write and select 
    operations are usually managed with a thread-specific select that switches to another 
    thread if the running threads have to wait for data. If the user thread packages are 
    integrated in the standard libs (FreeBSD and BSDI threads) the thread package requires 
    less overhead than thread packages that have to map all unsafe calls (MIT-pthreads, FSU 
    Pthreads and RTS threads). In some environments (for example, SCO), all system calls are 
    thread-safe so the mapping can be done very easily (FSU Pthreads on SCO). Downside: All 
    mapped calls take a little time and it's quite tricky to be able to handle all situations. 
    There are usually also some system calls that are not handled by the thread package (like 
    MIT-pthreads and sockets). Thread scheduling isn't always optimal. </li>
  <li>User threads in separate processes. Thread switching is done by the kernel and all data 
    are shared between threads. The thread package manages the standard thread calls to allow 
    sharing data between threads. LinuxThreads is using this method. Downside: Lots of 
    processes. Thread creating is slow. If one thread dies the rest are usually left hanging 
    and you must kill them all before restarting. Thread switching is somewhat expensive. </li>
  <li>Kernel threads. Thread switching is handled by the thread library or the kernel and is 
    very fast. Everything is done in one process, but on some systems, <code>ps</code> may 
    show the different threads. If one thread aborts the whole process aborts. Most system 
    calls are thread-safe and should require very little overhead. Solaris, HP-UX, AIX and 
    OSF1 have kernel threads. </li>
</ul>

<p>In some systems kernel threads are managed by integrating user level threads in the 
system libraries. In such cases, the thread switching can only be done by the thread 
library and the kernel isn't really ``thread aware''. </p>

<hr>

<p>Go to the <a href="manual_Introduction.html">first</a>, <a href="manual_TODO.html">previous</a>, 
<a href="manual_Regexp.html">next</a>, <a href="manual_Concept_Index.html">last</a> 
section, <a href="manual_toc.html">table of contents</a>. </p>
</body>
</html>