mysql signal 11
Greg 'groggy' Lehey
grog at mysql.com
Thu Jul 13 03:16:48 UTC 2006
On Wednesday, 12 July 2006 at 10:05:17 -0700, Jeremy Chadwick wrote:
> On Wed, Jul 12, 2006 at 06:43:01PM +0200, Koen Martens wrote:
>> Hi All,
>> Recently came across:
Unfortunately, this message doesn't give much information about the
cause of the problems.
>> I tried mysql-5.0.22 as a freebsd package, tried the official mysql
>> binary for freebsd-6.x and tried a fresh compile from the mysql
>> source tarball, all with the same problem.
>> I then tried the 4.1 binary from mysql.com, that worked fine, also
>> tried the 5.1 beta binary from mysql.com, and that was fine too.
>> Not sure what to do with this info, i'll probably try to make a
>> test-case for it and submit it to the mysql bug system.
(Koen) Yes, please do.
> I've experienced this exact problem (with current versions of MySQL,
> as well as older (4.0 and 4.1)). I ended up fixing it by doing the
> following on our 5.5-STABLE (which has been world'd since
> 5.2-STABLE, in case there's any concern):
You can't really know if it's the exact problem or not. A SIGSEGV is
a very unspecific problem. At MySQL, we've seen a number of different
problems with FreeBSD, many of which result in a SIGSEGV. In this
particular case, Koen reported that the problem only happens on 5.0,
not on 4.1 or 5.1. You report that you've had it on all versions
you've tried. That tends to suggest that these are two different
problems, but we can't confirm that either based on the evidence at
You might like to take a look at
http://dev.mysql.com/doc/refman/5.0/en/debugging-server.html ; we can
certainly do with the information requested there. Note also
http://bugs.mysql.com/bug.php?id=19496 , which was caused by a bug in
the thread library. It was fixed by 5.5, I think, but potentially
it's Koen's problem.
> 1) Kernel: use SCHED_4BSD not SCHED_ULE
> 2) Kernel: use ADAPTIVE_GIANT
> 2) Kernel: Increasing size limits using loader.conf variables:
> (The machine has 1GB RAM; note the sizes are topped out at
> 768MB, since that could induce a kernel panic due to
> memory exhaustion)
> 4) MySQL tuning: increased packet size (which fixed segfault;
> possibly related?)
> set-variable = max_allowed_packet=32M
> 5) MySQL tuning: didn't require much, but we did set some higher
> limits for join/sort/read_buffer_size (128M).
This isn't really a fix, it's a workaround. It's also rather
extensive. Have you confirmed that *all* of these are necessary to
make the problem go away?
In general: at MySQL, we *are* seriously concerned about reliability.
But before we can fix it, we need reports that help us to identify the
problem. Feel free to enter bug reports (after reading the manual).
And yes, it's a pain getting all this information together. I can
understand that you might not want to do so. That's your choice; but
if we can't reproduce a bug, or at least have a reasonable idea where
it's coming from, we can't do much about it.
Greg Lehey, Senior Software Engineer, Online Backup
MySQL AB, http://www.mysql.com/
Echunga, South Australia
Phone: +61-8-8388-8286 Mobile: +61-418-838-708
VoIP: sip:4484 at sip.mysql.com, sip:0871270137 at sip.internode.on.net
Are you MySQL certified? http://www.mysql.com/certification/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20060713/e1adb187/attachment.pgp
More information about the freebsd-ports