On Monday 11 June 2001 08:30, Haapanen, Tom wrote:
> Our normally reliable back-end server for our web site has now gone
> completely crazy ... it's falling over every few seconds. Automatic
> restarts are nice, but it really makes the web site unusable.
>
> 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.
> 010611 10:06:28 mysqld restarted
> /usr/local/libexec/mysqld: ready for connections
> 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.
> 010611 10:06:30 mysqld restarted
> /usr/local/libexec/mysqld: ready for connections
> 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.
> 010611 10:06:32 mysqld restarted
> /usr/local/libexec/mysqld: ready for connections
>
> There is very little information available here. I have tried check table,
> and myisamchk with -r, -o and -e options ... and no help.
>
> This is running MySQL 3.23.36 on NetBSD/i386 1.4.1. Are there any
> significant bug fixes in 3.23.38 to make it worthwhile downloading, building
> and installing it?
There are, of course, bugfixes in 3.23.38 that make it worth downloading. If
there were not, we would not have released it :-)
However, I would not think that you are hitting one of the bugs we fixed.
Unfortunately, our internal backtracer works only on Linux, so on NetBSD you
are just getting the info that SIGSEGV was received, but no more details. The
frequency of coredumps, though, indicates that very likely, the problem is
something like a bad/wrong shared library, bad kernel, bad RAM, etc.
We also are aware of the following phenomenon that we have still been unable
to explain rationally:
If you compile with gcc and do CXX=gcc ( this forces exclusion of libstdc++
from linking) and CXXFLAGS="-fno-exceptions -fno-rtti" ( one turns off
exceptions, the other turns off dynamic casts) strange problems tend to
disappear. At this point not sure which extra baggage feature causes the
problems - it is very possible that all three do. However, this really does
not matter - MySQL does not need any of the three at all, and you get a
cleaner binary anyway if you turn them off.
I have tried to investigate the issue and looked for the culprit code that
gets executed behind the scenes ( MySQL itself never calls libstdc++
routines, never uses exceptions, and never does dynamic casts) that could
cause a problem with threads, but have not spent enough time to find it.
--
MySQL Development Team
For technical support contracts, go to https://order.mysql.com/
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / 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
