Comment 9 for bug 585688

Revision history for this message
John Rosauer (john-rosauer) wrote : Re: [Bug 585688] Re: maridb crashes in federatedx code

Hi Paul,

It's happening all the time. An example of a table is below.

It crashed when browsing the table with the MySQL Windows GUI. It must do a
'SELECT COUNT(*)' to determine the number of rows, but probably does more.

CREATE TABLE `comdata`.`IAFTERC` (
  `ASKYC1` char(6) NOT NULL,
  `ASG9NO` decimal(9,0) NOT NULL,
  `ASIMNB` decimal(9,0) NOT NULL,
  `ASINNB` decimal(3,0) NOT NULL,
  `ASDPCD` char(11) NOT NULL,
  `ASE9SS` char(1) NOT NULL,
  `ASFBSS` char(1) NOT NULL,
  `ASSEST` char(1) NOT NULL,
  `ASFASS` char(1) NOT NULL,
  `ASUGST` char(1) NOT NULL,
  `ASIINB` decimal(9,0) NOT NULL,
  `ASBBTM` char(10) NOT NULL,
  `ASBGD8` decimal(7,0) NOT NULL,
  `ASDYD8` decimal(6,0) NOT NULL
) ENGINE="FEDERATED" CONNECTION="mysql://DSLMIINT:mylmiint@au-db-syd006
:3306/INTMIDDTA/IAFTERC";

On 27 May 2010 20:47, Paul McCullagh <email address hidden> wrote:

> Hi John,
>
> On May 27, 2010, at 9:12 AM, John Rosauer wrote:
>
> > I thought, when using MariaDB, when you used Federated Tables it uses
> > FederatedX instead?
>
> As far as I know, if you create a table with ENGINE=FEDERATED, then
> the table will be handled by the FederatedX engine. The old Federated
> engine is disabled.
>
> >
> > Sorry, I don't have the time to do testing at the moment and there
> > are other
> > people are trying to migrate data; I'll have more chance towards the
> > middle
> > of next week.
>
> No problem!
>
> > We will get to helping you resolve this, we have to :)
>
> You have already helped us by reporting the bug. :)
>
> --
> 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
>