MySQL Bugs: #47113: MySqld got signal 4

Bug #47113	MySqld got signal 4
Submitted:	3 Sep 2009 19:27	Modified:	10 Jan 2010 11:45
Reporter:	George Keenan	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server: General	Severity:	S2 (Serious)
Version:	5.1.37	OS:	IBM i (6.1)
Assigned to:		CPU Architecture:	Any

Description:
090903 13:18:21 - mysqld got signal 4 ;                                           
This could be because you hit a bug. It is also possible that this binary         
or one of the libraries it was linked against is corrupt, improperly built,       
or misconfigured. This error can also be caused by malfunctioning hardware.       
We will try our best to scrape up some info that will hopefully help diagnose     
the problem, but since we have already crashed, something is definitely wrong     
and this may fail.                                                                
                                                                                  
key_buffer_size=8384512                                                           
read_buffer_size=131072                                                           
max_used_connections=2                                                            
max_threads=151                                                                   
threads_connected=2                                                               
It is possible that mysqld could use up to                                        
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 338289 K    
bytes of memory                                                                   
Hope that's ok; if not, decrease some variables in the equation.                  
                                                                              

How to repeat:
Have not repealed error.

Suggested fix:
None

Thank you for the report.

Error code 4 means "Interrupted system call". Do you have idea when and after which query error occurred? Could you please attach full error log file in case if it contains more information?

Please also check OS error log files.

What I put in was the entire error file, unless there is more somewhere else.
I really don't know how to get at the query as it is comming from an app which I do not control.  The app runs in the Ruby on Rails framework.  In the development and initial testing was on a MySql server running in the same Linux server as the RoR framework. Performance was good.  One of the requirements of the production version was that the database be DB2i.  When the storage engine IBMDB2I came along it seemed a natural fit.
But for some complex queries that involve multiple tables the performand is unacceptably slow.  I was testing some of these queries when the database crashed.  If you could tell me how to get more information I will try to get it.

Thank you for the feedback.

Please try to get core file:
- use debug version of mysqld: this is mysqld-debug in the same directory where mysqld is located in case if you use binary package
- add option --core to the configuration file
- check OS settings, so OS would not prevent creation of core files

Try to run these queries again, check result, so in case if server crashes you would know which query caused this. Also you can turn general query log to ON for time when test runs.

After crash please send us core file, mysqld binary you used and query which caused the crash.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

I got the same problem here.

It happens on all tested configurations on an amd64 gentoo linux box. Here's the gentoo report:
http://bugs.gentoo.org/show_bug.cgi?id=177128

Always reproducable at the second start of the server. First start works fine with a fresh install, but no restart is possible without removing all data.

If that is an interrupted system call, may that be because of some kernel parameters or glibc optimizations?

please reopen this one,
Stephan

Thank you for the feedback.

Bug reopened.

Thanks,

may I add, I believe the problem is closely related to innodb. If I disable InnoDB in the config by setting "skip-innodb" the server starts normally.

HTH,
Stephan

Stephan,

thank you for the feedback. In Gentoo bug you wrote you use versions

dev-db/mysql-5.0.84 5.0.84-r1
and 
dev-db/mysql-community-5.0.77-r1

I assume they are from Gentoo distro? Could you please try with our latest (5.0.89) binaries available from http://dev.mysql.com/downloads and inform us if problem still exist? Use generic Linux binaries.

Hi Sveta,

I just tried with the current build (apparently this was 5.1.42) and it appears to work. At least it didn't crash, but I haven't tested anything else.

You are right, it is a gentoo ebuild but it builds from source so it could only be some weird compile related bug if that matters. Anyway, I'll ask at gentoo for a version bump to your 5.1.42 and see if it does the job too. In which case we could consider this done.

Cheers,
S.

Stephan,

thank you for the feedback. Closing this report as "Can't repeat" for now.