On Sunday 06 May 2001 20:06, Stephan Skusa wrote:
> Hello,
>
> I've got a problem:
>
> My MySQL-Server gets signal 11 almost every day arround 0:00 am ... I have a
> nice
> mrtg - graph showing this ... ;o)
>
> In fact every time the server crashes the statement shown in the server.log
> (or a
> similar one with other memID) is executed.
>
> topsitesTEMP is a temporary table. Every time I execute this statement
> manualy
> using tool mysql everything works fine.
>
> TIA
> Stephan Skusa
>
>
> mysqld got signal 11;
> The manual section 'Debugging a MySQL server' tells you how to use a
> stack trace and/or the core file to produce a readable backtrace that may
> help in finding out why mysqld died
> Attemping backtrace. You can use the following information to find out
> where mysqld died. If you see no messages after this, something went
> terribly wrong
> stack range sanity check, ok, backtrace follows
> 0x4009365d
> 0x80d7664
> 0x80b7d2d
> 0x80dab94
> 0x80dab19
> 0x80c3629
> 0x80c67e2
> 0x80c27f3
> 0x80c1b57
> stack trace successful, now will try to get some
> variables. Some pointers may be invalid and cause dump abort
> thd->query at 0x84af148 = SELECT myROWNUM, histRANKING FROM topsitesTEMP
> WHERE memID=12800
> thd->thread_id = 17276
> successfully dumped variables, if you ran with --log
> take a look at the details of what thread 17276 did to cause the crash.
> In some cases of really bad corruption, this value can be invalid
> Please use the information above to create a repeatable
> test case for the crash, and send it to [EMAIL PROTECTED]
>
> Number of processes running now: 0
> 010504 23:56:38 mysqld restarted
> /usr/local/mysql-3.23.33/libexec/mysqld: Warten auf Verbindungen.
>
>
>
Some things to do:
* Can you resolve those stack traces with resolve_stack_dump ? Follow
instructions in http://www.mysql.com/doc/U/s/Using_stack_trace.html
* What is the structure and type of topsitesTEMP?
* Can you write a script to take a backup of topsitesTEMP every time before
you expect a crash? This will be tricky if topsitesTEMP is a heap or
temporary table.
* You may also want to check if changing the table to a different type helps
avoid the coredump - this will give us an idea where the bug is.
* Does the bug go away if you use our latest ( 3.23.37) binary?
* How big is your key buffer, record_buffer, and sort_buffer, and how many
concurrent connections at the time of the crash? I am asking this because it
looks like you have built the binary yourself, which means that most likely
you have linked it against default LinuxThreads, and it has problems when you
get up to 600 connections, or even less if mysqld is using up a lot of memory
already.
--
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
