I don't know, they are migrating data and I'm not in position to interrupt
them with debugging tests, sorry.

On 26 May 2010 17:36, Arjen Lentz <email address hidden> wrote:

> > It happened four times in the last couple of days, so I am confident
> > it's reproducible.  Just need to find the time.
>
> Note that your original report does not state anything about what you
> were doing at the time of the segfault.
>
> --
> maridb crashes in federatedx code
> https://bugs.launchpad.net/bugs/585688
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Maria: New
>
> Bug description:
> Version: MariaDB-server-5.1.44-75.el5.x86_64
> One federated table existed.
> It happened again today after the federated had been removed, but some new
> ones had been created.
>
> 100525 11:41:56 [Note] /usr/sbin/mysqld: ready for connections.
> Version: '5.1.44-MariaDB-mariadb75-log'  socket:
> '/var/lib/mysql/mysql.sock'  port: 3306  (MariaDB - http://mariadb.com/)
> 100525 11:41:56 [Note] Slave I/O thread: connected to master '
> replication@10.72.15.21:3306',replication started in log
> 'mysql-bin.000004' at position 638859063
> 100525 12:52:33 - 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=402653184
> read_buffer_size=2097152
> max_used_connections=23
> max_threads=153
> threads_connected=5
> It is possible that mysqld could use up to
> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =
> 1021479 K
> bytes of memory
> Hope that's ok; if not, decrease some variables in the equation.
>
> thd: 0x993de40
> 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 = 0x414b5110 thread_stack 0x48000
> /usr/sbin/mysqld(my_print_stacktrace+0x35)[0x955135]
> /usr/sbin/mysqld(handle_segfault+0x32f)[0x5df10f]
> /lib64/libpthread.so.0[0x323d80e930]
> /lib64/libpthread.so.0(pthread_mutex_lock+0x0)[0x323d808ac0]
> /usr/sbin/mysqld(_ZN14federatedx_txn12release_scanEv+0x67)[0x794247]
> /usr/sbin/mysqld(_ZN13ha_federatedx4infoEj+0x83)[0x78f2c3]
> /usr/sbin/mysqld[0x6e818c]
>
> /usr/sbin/mysqld(_Z14get_all_tablesP3THDP10TABLE_LISTP4Item+0x8a1)[0x6eb911]
>
> /usr/sbin/mysqld(_Z24get_schema_tables_resultP4JOIN23enum_schema_table_state+0x1d1)[0x6e41b1]
> /usr/sbin/mysqld(_ZN4JOIN4execEv+0x400)[0x65ba10]
>
> /usr/sbin/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x14e)[0x65da6e]
>
> /usr/sbin/mysqld(_Z13handle_selectP3THDP6st_lexP13select_resultm+0x167)[0x65e367]
> /usr/sbin/mysqld[0x5eb5c0]
> /usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x739)[0x5ee999]
> /usr/sbin/mysqld(_Z11mysql_parseP3THDPKcjPS2_+0x1e5)[0x5f3f85]
>
> /usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x9e6)[0x5f4986]
> /usr/sbin/mysqld(_Z10do_commandP3THD+0xe6)[0x5f5576]
> /usr/sbin/mysqld(handle_one_connection+0x9e)[0x5e7bce]
> /lib64/libpthread.so.0[0x323d806617]
> /lib64/libc.so.6(clone+0x6d)[0x3f990d3c2d]
> Trying to get some variables.
> Some pointers may be invalid and cause the dump to abort...
> thd->query at 0x2aaacd14a078 is an invalid pointer
> thd->thread_id=9251
> thd->killed=NOT_KILLED
> The manual page at http://dev.mysql.com/doc/mysql/en/crashing.htmlcontains
> information that should help you find out what is causing the crash.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/maria/+bug/585688/+subscribe
>