> > First, make sure to follow the instructuctions in the manual on symbolic
> > resolve of the stack trace. Without it, numeric trace is not much help,
> > especially when you built your own binary and we do not have a symbol
> table.
> >
> This is output of resolve_stack_dump
>
> 0x813744a pthread_sighandler + 150
> 0x8137ed0 __pthread_lock + 32
> 0x813465d pthread_cond_broadcast + 17
> 0x807c2ec close_connections__Fv + 460
> 0x8080306 kill_server_thread__FPv + 78
> 0x8135846 pthread_start_thread + 182
> 0x815d60a thread_start + 4
This is interesting - the backtrace indicates that we either hit some
bug/inconsistency inside thread library or the mutex structure is invalidated
when we call pthread_cond_broadcast() which could be some rare, very hard to
repeat bug.
Do you often shut your server down? The trace indicates that the bug was hit
while you were shutting down the server.
Another possibility is that you have bad RAM segment or that there is some
corruption in your libc. It is possible for many applications to run just
fine on bad RAM if they never hit the bad area, but a small, normally
insignficant change could alter the code in such a way that it starts using
bad RAM and crashes.
So the suggested plan of action is:
* double-check your hardware, especially RAM
* use our binary
If the above does not fix it, keep track of all the traces, and keep sending
us their symbolic resolutions. If there is indeed a pattern that the crash
always happens on shutdown, have all of your shutdown scripts run show
processlist before issuing shutdown command.
As you can imagine, shutdown code is not something that gets tested as
thoroughly as the rest of the code - part of the problem is the difficulty in
testing it, and difficulty for the user to create a repeatable bug report. At
the same time, there is a lot of potential for bugs in that code, as the
system could be in a various number of states when shutdown begins, and it is
very possible that we have overlooked some condition that turns out fatal in
your case.
--
MySQL Development Team
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sasha Pachev <[EMAIL PROTECTED]>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/
/_/ /_/\_, /___/\___\_\___/ Provo, Utah, USA
<___/
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
