Hi Mark,

Thank you very much for replying! I did open a bug for this last night
after I e-mailed:

http://bugs.mysql.com/?id=25460

As for reproducing, we're working on that at the moment. This happened
on a production system, so we worked first to stop the hemorrhaging.
Currently, we moved the high volume tables to InnoDB as a stop gap. I
suppose an important piece of information is that we're running MySQL
on Solaris 10. We moved the DB from a SPARC box to Solaris 10 X64 box
and it happened again. We're running on top of ZFS, and that appears
to be sucking down a majority of the system RAM, so we're wondering if
that is causing the problem. Though at the time of crash there's
typically 500MB or so free out of 8GB. I was reading that whereas
Linux will allow overcommittment of RAM, Solaris returns a NULL to a
malloc when there's no more memory. Could this cause the behavior?

We will turn on the core file. The funny thing is this happened again,
and we didn't get any debugging information outside of the usual
friendly message that MySQL had crashed and the output of a few
memory-related my.cnf settings. This was despite having --with-debug
on. We did run --with-debug=full on and had some serious performance
issues. So we're going to try and repro on a dev system by exhausting
its RAM.

This database is stuffing e-mails into itself, so I'm wondering if it
could be a strange character that's not properly escaped. We'll get
y'all a core and a stack trace.


Thank you again. Any help is very much appreciated.

Best Regards,
Jason

On 1/8/07, Mark Leith <[EMAIL PROTECTED]> wrote:
Hi Jason,

Jason J. W. Williams wrote:
> Hello,
>
> We've been getting random crashes on our MySQL servers running MyISAM
> tables for the last month, its gotten very bad in the last two weeks.
> This has occurred on both 5.0.27, 5.1.11 and 5.1.15-nightly20070103.
>
> It crashes the tables with high queries per second. We've fixed the
> issue on one of the servers by changing its tables to InnoDB. We can't
> do that however on another server, which we turned debugging on
> instead. It appears to be an assertion failure, the error message from
> the MySQL debugging code is:
>
> Assertion failed: fixed == 1, file item.h, line 1601
>
>
> Any help is greatly appreciated. Should we report this as a bug?

Any crashing is most certainly a bug, so if you could gather as much
information on this as possible and report a bug that would be great.

Please include:

o The full section of the error log for the time of the crash
o If there is a stacktrace reported, the resolved trace following:
  o http://dev.mysql.com/doc/refman/5.0/en/using-stack-trace.html
o If you could turn on core files and upload the core file, and mysqld
binary used to create it, as tar.gz to:
  o ftp://ftp.mysql.com/pub/mysql/upload
  o Link this in the bug report as well

Do you have any way to reproduce this as yet?

Cheers,

Mark

--
Mark Leith, Support Engineer
MySQL AB, Worcester, England, www.mysql.com
Are you MySQL certified?  www.mysql.com/certification



--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

Reply via email to