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
>
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` ( "mysql: //DSLMIINT: mylmiint@ au-db-syd006 /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=
:3306/INTMIDDTA
On 27 May 2010 20:47, Paul McCullagh <email address hidden> wrote:
> Hi John, /bugs.launchpad .net/bugs/ 585688 server- 5.1.44- 75.el5. x86_64 MariaDB- mariadb75- log' socket: mysql/mysql. sock' port: 3306 (MariaDB - http:// mariadb. com/) 10.72.15. 21:3306' ,replication started in log size=402653184 size=2097152 connections= 23 size)*max_ threads = mysqld( my_print_ stacktrace+ 0x35)[0x955135] mysqld( handle_ segfault+ 0x32f)[ 0x5df10f] libpthread. so.0[0x323d80e9 30] libpthread. so.0(pthread_ mutex_lock+ 0x0)[0x323d808a c0] mysqld( _ZN14federatedx _txn12release_ scanEv+ 0x67)[0x794247] mysqld( _ZN13ha_ federatedx4info Ej+0x83) [0x78f2c3] mysqld[ 0x6e818c] mysqld( _Z14get_ all_tablesP3THD P10TABLE_ LISTP4Item+ 0x8a1)[ 0x6eb911] mysqld( _Z24get_ schema_ tables_ resultP4JOIN23e num_schema_ table_state+ 0x1d1)[ 0x6e41b1] mysqld( _ZN4JOIN4execEv +0x400) [0x65ba10] mysqld( _Z12mysql_ selectP3THDPPP4 ItemP10TABLE_ LISTjR4ListIS1_ ES2_jP8st_ orderSB_ S2_SB_yP13selec t_resultP18st_ select_ lex_unitP13st_ select_ lex+0x14e) [0x65da6e] mysqld( _Z13handle_ selectP3THDP6st _lexP13select_ resultm+ 0x167)[ 0x65e367] mysqld[ 0x5eb5c0] mysqld( _Z21mysql_ execute_ commandP3THD+ 0x739)[ 0x5ee999] mysqld( _Z11mysql_ parseP3THDPKcjP S2_+0x1e5) [0x5f3f85] mysqld( _Z16dispatch_ command19enum_ server_ commandP3THDPcj +0x9e6) [0x5f4986] mysqld( _Z10do_ commandP3THD+ 0xe6)[0x5f5576] mysqld( handle_ one_connection+ 0x9e)[0x5e7bce] libpthread. so.0[0x323d8066 17] libc.so. 6(clone+ 0x6d)[0x3f990d3 c2d] NOT_KILLED dev.mysql. com/doc/ mysql/en/ crashing. htmlcontains /bugs.launchpad .net/maria/ +bug/585688/ +subscribe
>
> 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:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Maria: New
>
> Bug description:
> Version: MariaDB-
> 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-
> '/var/lib/
> 100525 11:41:56 [Note] Slave I/O thread: connected to master '
> replication@
> '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_
> read_buffer_
> max_used_
> max_threads=153
> threads_connected=5
> It is possible that mysqld could use up to
> key_buffer_size + (read_buffer_size + sort_buffer_
> 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/
> /usr/sbin/
> /lib64/
> /lib64/
> /usr/sbin/
> /usr/sbin/
> /usr/sbin/
>
> /usr/sbin/
>
> /usr/sbin/
> /usr/sbin/
>
> /usr/sbin/
>
> /usr/sbin/
> /usr/sbin/
> /usr/sbin/
> /usr/sbin/
>
> /usr/sbin/
> /usr/sbin/
> /usr/sbin/
> /lib64/
> /lib64/
> 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=
> The manual page at http://
> information that should help you find out what is causing the crash.
>
> To unsubscribe from this bug, go to:
> https:/
>