maridb crashes in federatedx code

Hi John - it's not clear (to me at least) what sequence of events/commands triggered the segfault.
Clearly there's a problem, the server should never segfault so there's definitely a bug somewhere, but it would really help the MariaDB engineers if there is a reproducible sequence of events.

I know, but it hasn't been possible, need to do a controlled test. However,
nothing fancy is being done.

On 26 May 2010 14:05, "Arjen Lentz" <email address hidden> wrote:

Hi John - it's not clear (to me at least) what sequence of events/commands
triggered the segfault.
Clearly there's a problem, the server should never segfault so there's
definitely a bug somewhere, but it would really help the MariaDB engineers
if there is a reproducible sequence of events.

--
maridb crashes in federatedx code
https://bugs.launchpad.net/bugs/585688
You received this bug ...

Hi Arjen,

It happened four times in the last couple of days, so I am confident
it's reproducible. Just need to find the time.

thanks,
john

On 26 May 2010 14:00, Arjen Lentz <email address hidden> wrote:

> Hi John - it's not clear (to me at least) what sequence of events/commands
> triggered the segfault.
> Clearly there's a problem, the server should never segfault so there's
> definitely a bug somewhere, but it would really help the MariaDB engineers
> if there is a reproducible sequence of events.
>
> --
> 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/mysql...

> 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.

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_parseP3THDPKcjP...

I guess an important question here is: are you using federatedx tables?

I suspect that you are not, which makes the crash even more strange.

The stack trace does give us a good clue as to where to look for the problem:

get_all_tables() is calling ha_federatedx::info() which calls federatedx_txn::release_scan(), which crashes.

So what is federatedx doing that makes it crash if it actually has no tables?

Hi Paul,

I thought, when using MariaDB, when you used Federated Tables it uses
FederatedX instead?

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. We will get to helping you resolve this, we have to :)

cheers,
john

On 26 May 2010 17:56, Paul McCullagh <email address hidden> wrote:

> I guess an important question here is: are you using federatedx tables?
>
> I suspect that you are not, which makes the crash even more strange.
>
> The stack trace does give us a good clue as to where to look for the
> problem:
>
> get_all_tables() is calling ha_federatedx::info() which calls
> federatedx_txn::release_scan(), which crashes.
>
> So what is federatedx doing that makes it crash if it actually has no
> tables?
>
> --
> 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...

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. :)

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. I...

Hi Paul,

I wonder if it's possible to add the old Federated tables to MariaDB, called
FEDERATEDOLD, say, so we can continue using MariaDB?

This will also prove it is the FederatedX tables causing this.

Otherwise we'll have to move to the standard version.

Until we pick a version, unfortunately, we can't pay for support.

regards,
John

On 26 May 2010 17:56, Paul McCullagh <email address hidden> wrote:

> I guess an important question here is: are you using federatedx tables?
>
> I suspect that you are not, which makes the crash even more strange.
>
> The stack trace does give us a good clue as to where to look for the
> problem:
>
> get_all_tables() is calling ha_federatedx::info() which calls
> federatedx_txn::release_scan(), which crashes.
>
> So what is federatedx doing that makes it crash if it actually has no
> tables?
>
> --
> 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/my...

Hi, John!

Yes, it is.

But could you please answer Paul's question - are you or are you not
using federated tables ?

On Jun 08, John Rosauer wrote:
>
> I wonder if it's possible to add the old Federated tables to MariaDB,
> called FEDERATEDOLD, say, so we can continue using MariaDB?
>
> On 26 May 2010 17:56, Paul McCullagh <email address hidden>
> wrote:
>
> > I guess an important question here is: are you using federatedx
> > tables?
> >
> > I suspect that you are not, which makes the crash even more strange.
> >
> > The stack trace does give us a good clue as to where to look for the
> > problem:
> >
> > get_all_tables() is calling ha_federatedx::info() which calls
> > federatedx_txn::release_scan(), which crashes.
> >
> > So what is federatedx doing that makes it crash if it actually has
> > no tables?
> >
Regards,
Sergei

Hi Sergii,

So sorry, I thought I did answer that. Yes, we are using Federated tables;
they point to different tables in schema within the same database (there is
a good reason).

I assumed when Federated tables are used, FederatedX tables are actually
used.

The data is being migrated from another database, so the Federated table
will, at some point, have no data (during migration).

Your answer "Yes, it is." implies we can use the old Federated tables. If
so, how?

much thanks,
John

On 8 June 2010 18:33, Sergei <email address hidden> wrote:

> Hi, John!
>
> Yes, it is.
>
> But could you please answer Paul's question - are you or are you not
> using federated tables ?
>
> On Jun 08, John Rosauer wrote:
> >
> > I wonder if it's possible to add the old Federated tables to MariaDB,
> > called FEDERATEDOLD, say, so we can continue using MariaDB?
> >
> > On 26 May 2010 17:56, Paul McCullagh <email address hidden>
> > wrote:
> >
> > > I guess an important question here is: are you using federatedx
> > > tables?
> > >
> > > I suspect that you are not, which makes the crash even more strange.
> > >
> > > The stack trace does give us a good clue as to where to look for the
> > > problem:
> > >
> > > get_all_tables() is calling ha_federatedx::info() which calls
> > > federatedx_txn::release_scan(), which crashes.
> > >
> > > So what is federatedx doing that makes it crash if it actually has
> > > no tables?
> > >
> Regards,
> Sergei
>
> --
> 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: Incomplete
>
> 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......

"Yes, it is" was an answer to "if it's possible to add the old Federated tables to MariaDB?".
It doesn't mean you can use old federated in MariaDB right now.

I've just committed a change that allows federated engine to be built:
http://lists.askmonty.org/pipermail/commits/2010-June/000078.html

it's not pushed yet as I am fixing the test suite to support testing of both engines loaded dynamically.

Are you using our binary tarball ? source tarball ? deb, rpm or anything else ?

Hi Sergii,

Thanks!!

We are currently using these rpms:

MariaDB-client-5.1.44-75.el5.x86_64.rpm
MariaDB-server-5.1.44-75.el5.x86_64.rpm
MariaDB-shared-5.1.44-75.el5.x86_64.rpm

Not quite the latest version but I can upgrade if you think it's useful.

regards,
John

On 9 June 2010 18:22, Sergei <email address hidden> wrote:

> "Yes, it is" was an answer to "if it's possible to add the old Federated
> tables to MariaDB?".
> It doesn't mean you can use old federated in MariaDB right now.
>
> I've just committed a change that allows federated engine to be built:
> http://lists.askmonty.org/pipermail/commits/2010-June/000078.html
>
> it's not pushed yet as I am fixing the test suite to support testing of
> both engines loaded dynamically.
>
> Are you using our binary tarball ? source tarball ? deb, rpm or anything
> else ?
>
> --
> 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: Incomplete
>
> 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(_ZN4JOI...

John, I've pushed a fix that allows to use old federated with mariadb. It is not in rpm yet and not in any release, but if you're willing to build from source you can use it. Otherwise you can wait for the next release, although I cannot guarantee that this will get into binary rpms - it will certainly be in the source tarballs, but as for rpms it's not decided yet :(

Hi John

On 08/06/2010, at 7:54 PM, John Rosauer wrote:
> Yes, we are using Federated tables; they point to different tables
> in schema
> within the same database (there is a good reason).

I figure by the word "database" in this context you actually mean
"database server instance", i.e. the same running mysqld ?
If I read the above correctly, you're essentially doing a federated
connection back to the same server. While there's still an indication
that there is a bug, if this what you're doing, there might be a
workaround: use a VIEW instead. In MySQL/MariaDB, regular views are
updateable.

> The data is being migrated from another database, so the Federated
> table
> will, at some point, have no data (during migration).

Regards,
Arjen.
--
Arjen Lentz, Exec.Director @ Open Query (http://openquery.com)
Exceptional Services for MySQL at a fixed budget.

Follow our blog at http://openquery.com/blog/
OurDelta: packages for MySQL and MariaDB @ http://ourdelta.org

Hi Arjen,

Yes, and VIEWS should do the job. I should have thought of this myself and
I have told the developers.

Federated tables will still be needed, though.

The developers are going to change their code so they don't need Federated
tables or views, so we have time to wait.

cheers,
John

On 16 June 2010 09:52, Arjen Lentz <email address hidden> wrote:

> Hi John
>
> On 08/06/2010, at 7:54 PM, John Rosauer wrote:
> > Yes, we are using Federated tables; they point to different tables
> > in schema
> > within the same database (there is a good reason).
>
> I figure by the word "database" in this context you actually mean
> "database server instance", i.e. the same running mysqld ?
> If I read the above correctly, you're essentially doing a federated
> connection back to the same server. While there's still an indication
> that there is a bug, if this what you're doing, there might be a
> workaround: use a VIEW instead. In MySQL/MariaDB, regular views are
> updateable.
>
>
> > The data is being migrated from another database, so the Federated
> > table
> > will, at some point, have no data (during migration).
>
>
> Regards,
> Arjen.
> --
> Arjen Lentz, Exec.Director @ Open Query (http://openquery.com)
> Exceptional Services for MySQL at a fixed budget.
>
> Follow our blog at http://openquery.com/blog/
> OurDelta: packages for MySQL and MariaDB @ http://ourdelta.org
>
> --
> 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: Incomplete
>
> 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/mys...

Hi John

On 16/06/2010, at 3:01 PM, John Rosauer wrote:
> Yes, and VIEWS should do the job. I should have thought of this
> myself and
> I have told the developers.
>
> Federated tables will still be needed, though.

Yep and of course nothing should crash the server, ever.

> The developers are going to change their code so they don't need
> Federated
> tables or views, so we have time to wait.

Great.

Regards,
Arjen.
--
Arjen Lentz, Exec.Director @ Open Query (http://openquery.com)
Exceptional Services for MySQL at a fixed budget.

Follow our blog at http://openquery.com/blog/
OurDelta: packages for MySQL and MariaDB @ http://ourdelta.org

Hi Sergii.

I'll wait for the moment, we can avoid federated tables at the moment. It's
too hectic trying to get the migration completed to find the time.

I'll give the standard mysql version which comes with redhat a go asap,
though, to see what happens.

thanks,
john

On 15 June 2010 21:24, Sergei <email address hidden> wrote:

> John, I've pushed a fix that allows to use old federated with mariadb.
> It is not in rpm yet and not in any release, but if you're willing to
> build from source you can use it. Otherwise you can wait for the next
> release, although I cannot guarantee that this will get into binary rpms
> - it will certainly be in the source tarballs, but as for rpms it's not
> decided yet :(
>
> --
> 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: Incomplete
>
> 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...

Hi John

On 17/06/2010, at 9:26 AM, John Rosauer wrote:
> I'll wait for the moment, we can avoid federated tables at the
> moment. It's
> too hectic trying to get the migration completed to find the time.
>
> I'll give the standard mysql version which comes with redhat a go
> asap,
> though, to see what happens.

Note that you're running a 5.1
You cannot just downgrade to 5.0. See the downgrade info in the MySQL
online manual.

You could grab stock 5.1 RPMs from dev.mysql.com, in that case just
make sure you comment out any MariaDB-specific config options.

Regards,
Arjen.
--
Arjen Lentz, Exec.Director @ Open Query (http://openquery.com)
Exceptional Services for MySQL at a fixed budget.

Follow our blog at http://openquery.com/blog/
OurDelta: packages for MySQL and MariaDB @ http://ourdelta.org

Hi,

I just upgraded one of the slaves to MariaDB1.47, the latest, and got it to
crash. It only crashes when using the MySQL Administrator GUI to query the
tables.

The debug with this new version provides better information, I think. See
below.

All the Federated tables point to the same database. Here is an example:

CREATE TABLE `IAUTASS` (
  `O8IMNB` decimal(9,0) NOT NULL,
  `O8INNB` decimal(3,0) NOT NULL,
  `O8AFNB` decimal(9,0) NOT NULL,
  `O8EAST` char(1) COLLATE latin1_general_cs NOT NULL,
  `O8EBST` char(1) COLLATE latin1_general_cs NOT NULL,
  `O8ECST` char(1) COLLATE latin1_general_cs NOT NULL,
  `O8EDST` char(1) COLLATE latin1_general_cs NOT NULL,
  `O8BANR` decimal(9,0) NOT NULL,
  `O8A3NR` decimal(9,0) NOT NULL,
  `O8C7NR` decimal(9,2) NOT NULL,
  `O8DCNR` decimal(3,0) NOT NULL,
  `O8C8NR` decimal(9,0) NOT NULL,
  `O8CJNR` decimal(3,0) NOT NULL,
  `O8IINB` decimal(9,0) NOT NULL,
  `O8BBTM` char(10) COLLATE latin1_general_cs NOT NULL,
  `O8BGD8` decimal(7,0) NOT NULL,
  `O8DYD8` decimal(6,0) NOT NULL
) ENGINE=FEDERATED DEFAULT CHARSET=latin1 COLLATE=latin1_general_cs
CONNECTION='mysql://DSLMIINT:mylmiint@au-db-syd030:3306/comdata/IAUTASS';

regards,
John

100617 12:56:38 [ERROR] 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=3
max_threads=153
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =
1021497 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x5ef53c0
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 = 0x40d2a100 thread_stack 0x48000
/usr/sbin/mysqld(my_print_stacktrace+0x2e) [0x960afe]
/usr/sbin/mysqld(handle_segfault+0x353) [0x5e0ba3]
/lib64/libpthread.so.0 [0x3e35c0eb10]
/usr/sbin/mysqld(federatedx_txn::acquire(st_federatedx_share*, bool,
federatedx_io**)+0x79) [0x7975e9]
/usr/sbin/mysqld(ha_federatedx::info(unsigned int)+0x1ce) [0x79266e]
/usr/sbin/mysqld [0x6eab3c]
/usr/sbin/mysqld(get_all_tables(THD*, TABLE_LIST*, Item*)+0x8a1) [0x6ee2c1]
/usr/sbin/mysqld(get_schema_tables_result(JOIN*,
enum_schema_table_state)+0x1d1) [0x6e6b51]
/usr/sbin/mysqld(JOIN::exec()+0x3ff) [0x65db9f]
/usr/sbin/mysqld(mysql_select(THD*, Item***, TABLE_LIST*, unsigned int,
List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*,
unsigned long long, select_result*, st_select_lex_unit*,
st_select_lex*)+0x14e) [0x65fbfe]
/usr/sbin/mysqld(handle_select(THD*, st_lex*, select_result*, unsigned
long)+0x167) [0x6604f7]
/usr/sbin/mysqld [0x5ed110]
/usr/sbin/mysqld(mysql_execute_command(THD*)+0x739) [0x5f04e9]
/usr/sbin/mysqld(mysql_parse(THD*, char co...

I tried repeat this by creating and indentical table as you had above and did some 'show' commands, but could not repeat the failure.

If you could compile MariaDB with the -g or with 'BUILD/compile-pentium-debug' it could help us locate and fix this bug. (This would give us the line number where things goes wrong).

I just created a wiki page: http://askmonty.org/wiki/Reporting_bug with information of how to do the above.

Also knowing the exact query that causes the failure would be of great usage.
The easiest way to find this one, would be to start mysqld with --log. In this case you can find the offending query in the mysql-data-dir/hostname.log file.

In any case, using federated to 'loopback' to the same database server is not recommended and is prone to deadlock.

I think I have an idea as to what may cause this crash.. I'll try to reproduce it and then fix it.

Hi Antony, Monty

On 20/07/2010, at 6:39 AM, Antony T Curtis wrote:
> In any case, using federated to 'loopback' to the same database server
> is not recommended and is prone to deadlock.
>
> I think I have an idea as to what may cause this crash.. I'll try to
> reproduce it and then fix it.

User reports that it's not just the existence of federatedx tables
that causes the problem.
It only occurs when he has such tables and talks to MariaDB using the
MySQL Administrator GUI.
If instead he uses MySQL Workbench or SQLYog, there are no crashes.

So there must be a command that MySQL Administrator GUI uses that
causes this crash in federatedx.
I'll be at client site this Thursday and will try to debug/trace this
problem if there's sufficient time.
But if you happen to have a MySQL Admininistrator install anyway you
may find it easy to reproduce that way anyway.

Regards,
Arjen.
--
Arjen Lentz, Exec.Director @ Open Query (http://openquery.com)
Exceptional Services for MySQL at a fixed budget.

Follow our blog at http://openquery.com/blog/
OurDelta: packages for MySQL and MariaDB @ http://ourdelta.org

Yes, Anthony, I agree, using a loopback federated table is not good. It was
intended as a short term work around.

On 20 July 2010 06:39, Antony T Curtis <email address hidden> wrote:

> In any case, using federated to 'loopback' to the same database server
> is not recommended and is prone to deadlock.
>
> I think I have an idea as to what may cause this crash.. I'll try to
> reproduce it and then fix it.
>
> --
> 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: Incomplete
>
> 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_parseP3THDPKcjPS...

I have successfully managed to recreate this bug and fix a couple of other bugs along the way.
The changes has been pushed to lp:~atcurtis/maria/federatedx for review.

On 25/07/2010, at 7:05 PM, Antony T Curtis wrote:
> I have successfully managed to recreate this bug and fix a couple of
> other bugs along the way.
> The changes has been pushed to lp:~atcurtis/maria/federatedx for
> review.

Antony can you describe what you recreated and what you changed/fixed?

Did you see my description of the prob, it was not related not the
existence of a federatedx table as such, or the loopback construct, it
was something MySQL Administrator did that caused a prob if a fedx
table exists.
I'd like to be sure that whatever you fixed covers this, before the
issue is marked resolved. cheers

--
Arjen Lentz, Exec.Director @ Open Query (http://openquery.com)
Exceptional Services for MySQL at a fixed budget.

Follow our blog at http://openquery.com/blog/
OurDelta: packages for MySQL and MariaDB @ http://ourdelta.org

Merge of federatedx tree done to MariaDB 5.1
This includes a couple of bug fixes for partition.
I will work with Patrick Galbraith to get the fixes into federatedx trunk