mysql signal 11

Greg 'groggy' Lehey grog at
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, that worked fine, also
>> tried the 5.1 beta binary from, 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 ; we can
certainly do with the information requested there.  Note also , 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:
>      kern.maxdsiz="805306368"
>      kern.dfldsiz="805306368"
>      kern.maxssiz="134217728"
>    (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
Echunga, South Australia
Phone: +61-8-8388-8286   Mobile: +61-418-838-708
VoIP:  sip:4484 at, sip:0871270137 at

Are you MySQL certified?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :

More information about the freebsd-ports mailing list