Bug #16616 mysqld 5.0.18 - segmentation fault (backtrace attached)
Submitted: 18 Jan 2006 20:18 Modified: 19 Feb 2006 18:09
Reporter: Pelat Guillaume Email Updates:
Status: No Feedback Impact on me:
None 
Category:MySQL Server Severity:S1 (Critical)
Version:5.0.18 OS:Linux (Linux)
Assigned to: CPU Architecture:Any

[18 Jan 2006 20:18] Pelat Guillaume
Description:
mysqld 5.0.18 crash after a few hours uptime with the following logs (memory limit has not been reached). The problem occured multiple times, with almost the same backtrace. It occured on a shared mysql server hosting about 8000 db / users. Privileges are flushed rather often on this db (users are added every minute). The problem always seems to occur with : thd->query at 0x86f11f0 = SHOW GRANTS

Here is a complete log : 
Version: '5.0.18-debug'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Gentoo Linux mysql-5.0.18
mysqld got signal 11;
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=16777216
read_buffer_size=131072
max_used_connections=23
max_connections=1000
threads_connected=6
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 272347 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0xb531ca98
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xb5b86d7c, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x81816b3
0xffffe420
0xb5b878dc
0x81a0677
0x81954c7
0x8194e4c
0x8193fa2
0xb7edeb2c
0xffffffdc
Stack trace seems successful - bottom reached
Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x86f11f0 = SHOW GRANTS
thd->thread_id=212354
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.

Here is the resolved backlog : 
0x81816b3 handle_segfault + 637
0xffffe420 _end + -141133488
0xb5b878dc _end + -1387327988
0x81a0677 _Z11mysql_parseP3THDPcj + 401
0x81954c7 _Z16dispatch_command19enum_server_commandP3THDPcj + 1367
0x8194e4c _Z10do_commandP3THD + 260
0x8193fa2 handle_one_connection + 480
0xb7edeb2c _end + -1350270884
0xffffffdc _end + -141126388

How to repeat:
I couldn't identify exactly what is causing the problem. It dies with: 
thd->query at 0x8854e60 = SHOW GRANTS
But i couldnt reproduce it when launching a manual SHOW GRANTS.
If the backtrace and details are not enough, i'll try to log all the queries.. (i'd rather avoid it if i could..).
[18 Jan 2006 22:37] Philippe Brand
Just came across what could be directly related. On a hardened-gentoo (with SSP), mysqld fails upon install (/usr/bin/mysql_install_db) with:

mysqld: stack smashing attack in function int mysql_prepare_table(THD*, HA_CREATE_INFO*, List<create_field>*, List<Key>*, bool, uint*, handler*, KEY**, uint*, int)()

Definitly stack problems around here...
[19 Jan 2006 18:09] Valeriy Kravchuk
Thank you for a problem report. Please, clarify, do you use one of the official MySQL binaries or some ebuild provided by Gentoo (as it seems), or something you build yourself from MySQL sources? Just to be sure...
[20 Feb 2006 0:00] Bugs System
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".
[16 Mar 2007 15:18] Auke Bruinsma
on my gentoo hardened with gcc: 

gcc (GCC) 3.4.6 (Gentoo Hardened 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.10

I get:

mysqld: stack smashing attack in function int mysql_prepare_table(THD*, HA_CREATE_INFO*, List<create_field>*, List<Key>*, bool, uint*, handler*, KEY**, uint*, int)()

when I do:  
emerge --config =dev-db/mysql-5.0.26-r2

which results in:

//usr/bin/mysql_install_db: line 217:  2269 Aborted                 /usr/sbin/mysqld --bootstrap --skip-grant-tables --basedir=/usr --datadir=/var/lib/mysql --skip-innodb --skip-bdb --skip-ndbcluster --user=mysql --max_allowed_packet=8M --net_buffer_length=16K

!!! ERROR: dev-db/mysql-5.0.26-r2 failed.
Call stack:
  ebuild.sh, line 1595:   Called qa_call 'pkg_config'
  ebuild.sh, line 38:   Called pkg_config
  ebuild.sh, line 1304:   Called mysql_pkg_config
  mysql.eclass, line 806:   Called die

!!! MySQL databases not installed
!!! If you need support, post the topmost build error, and the call stack if relevant.

If you need more version info, please let me know.
[16 Mar 2007 21:29] Sergei Golubchik
the last comment is copied to a separate bugreport - bug#27230