[Maria-developers] Why does name resolution stop in crash stack trace?
Hi, Look at today's crash report in maria-discuss@. A question not related to the cause of that crash: why do stack traces that go inside the storage engine cannot be resolved? Is something wrong with our build process? On Fri, Jun 13, 2014 at 08:15:39PM -0700, grantksupport@operamail.com wrote:
==> /var/log/mariadb/mariadb-err.log <== 140613 20:07:24 [ERROR] mysqld got signal 11 ;
...
Server version: 10.0.11-MariaDB-log key_buffer_size=268435456 read_buffer_size=1048576 max_used_connections=1 max_threads=66 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 601410 K bytes of memory Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0x7fcf132fa008 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... stack_bottom = 0x7fcf4a6e4e78 thread_stack 0x100000 /usr/local/mariadb/bin/mysqld(my_print_stacktrace+0x2e)[0xacb60e] /usr/local/mariadb/bin/mysqld(handle_fatal_signal+0x390)[0x6f5a10] /lib64/libpthread.so.0(+0xf9f0)[0x7fcf4ff2a9f0] /usr/local/mariadb/bin/mysqld[0x915cba] /usr/local/mariadb/bin/mysqld[0x909e27] /usr/local/mariadb/bin/mysqld[0x90a35b] /usr/local/mariadb/bin/mysqld[0x90c759] /usr/local/mariadb/bin/mysqld[0x9169d5] /usr/local/mariadb/bin/mysqld[0x8aaf2b] /usr/local/mariadb/bin/mysqld[0x8ab3cf] /usr/local/mariadb/bin/mysqld[0x8ab95a] /usr/local/mariadb/bin/mysqld[0x895e80] /usr/local/mariadb/bin/mysqld[0x89643f] /usr/local/mariadb/bin/mysqld[0x9657da] /usr/local/mariadb/bin/mysqld[0x965a16] /usr/local/mariadb/bin/mysqld[0x96a51d] /usr/local/mariadb/bin/mysqld[0x96ac28] /usr/local/mariadb/bin/mysqld[0x82de54] /usr/local/mariadb/bin/mysqld(_ZN7handler9ha_createEPKcP5TABLEP14HA_CREATE_INFO+0x70)[0x6fcbf0] /usr/local/mariadb/bin/mysqld(_Z15ha_create_tableP3THDPKcS2_S2_P14HA_CREATE_INFOP34st_mysql_const_unsigned_lex_string+0x220)[0x6fd560] /usr/local/mariadb/bin/mysqld(_Z16rea_create_tableP3THDP34st_mysql_const_unsigned_lex_stringPKcS4_S4_P14HA_CREATE_INFOP7handlerb+0xbb)[0x659d1b] /usr/local/mariadb/bin/mysqld[0x62e50d] /usr/local/mariadb/bin/mysqld(_Z26mysql_create_table_no_lockP3THDPKcS2_P14HA_CREATE_INFOP10Alter_infoPbi+0xd3)[0x62ee13] /usr/local/mariadb/bin/mysqld(_Z18mysql_create_tableP3THDP10TABLE_LISTP14HA_CREATE_INFOP10Alter_info+0xb6)[0x62ef76] /usr/local/mariadb/bin/mysqld(_Z21mysql_execute_commandP3THD+0x672d)[0x5be04d] /usr/local/mariadb/bin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x1d7)[0x5bf4f7] /usr/local/mariadb/bin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x15d7)[0x5c1057] /usr/local/mariadb/bin/mysqld(_Z24do_handle_one_connectionP3THD+0x20c)[0x66f0ec] /usr/local/mariadb/bin/mysqld(handle_one_connection+0x38)[0x66f138] /usr/local/mariadb/bin/mysqld[0x9d5184] /lib64/libpthread.so.0(+0x80db)[0x7fcf4ff230db] /lib64/libc.so.6(clone+0x6d)[0x7fcf4ebd390d]
Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fcf1143d020): CREATE TABLE menu_router (
BR Sergei -- Sergei Petrunia, Software Developer MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog
Hi, Sergey! On Jul 18, Sergey Petrunia wrote:
Hi,
Look at today's crash report in maria-discuss@. A question not related to the cause of that crash: why do stack traces that go inside the storage engine cannot be resolved? Is something wrong with our build process?
We resolve stack traces using addr2line utility (see mysys/my_addr_resolve.c). It takes the name of the executable as an argument. Dynamic plugins are not part of the executable - so they aren't resolved. There are other approaches to resolving a stack trace, they would resolve traces inside plugins, but they have drawbacks too: * libbfd (it's used by addr2line internally) - it's GPLv3 * backtrace_symbols() - doesn't show filenames and line numbers * libelf - extra dependency and not as ubiquitous as libbfd One can build mariadb with libbfd by specifying -DNOT_FOR_DISTRIBUTION=1 but the resulting binary cannot be legally distributed. libelf support is not currently implemented, but it should only take a couple of hours to add it. backtrace_symbols() - that's what MySQL is using. Regards, Sergei
participants (2)
-
Sergei Golubchik
-
Sergey Petrunia