MySQL Bugs: #19197: Update crashing the server.

Bug #19197	Update crashing the server.
Submitted:	19 Apr 2006 13:20	Modified:	19 Jun 2006 18:18
Reporter:	Gilberto Müller	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server	Severity:	S1 (Critical)
Version:	mysql-pro-5.0.20-linux-i686-glibc23	OS:	Linux (linux debian)
Assigned to:		CPU Architecture:	Any

Description:
Hi there folks!

After upgrading my slave server from 4.1.13 version, i had a problem replicating these updates:

I don't know if is a replication problem, but I don't think so.

update an, anparte Set Ap_Proprietario = 0 where An_Livro = "2" AND An_IdLivro = 66623 AND Ap_Anotacao = An_Id AND Ap_Proprietario = 1

update an, anparte Set Ap_Proprietario = 0 where An_Livro = "2" AND An_IdLivro = 3649 AND Ap_Anotacao = An_Id AND Ap_Proprietario = 1

update an, anparte Set Ap_Proprietario = 0 where An_Livro = "2" AND An_IdLivro = 47938 AND Ap_Anotacao = An_Id AND Ap_Proprietario = 1

The server entries in a loop, crashing all the time.

Master versions (working fine):
4.0.18-nt, 4.1.14-pro and 4.0.18-pro

####################################################################

Number of processes running now: 0
060419 10:24:07  mysqld restarted
060419 10:24:07  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
060419 10:24:07  InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 10 1628037531.
InnoDB: Doing recovery: scanned up to log sequence number 10 1628037531
InnoDB: In a MySQL replication slave the last master binlog file
InnoDB: position 0 28141934, file name logreplication.153
060419 10:24:07  InnoDB: Started; log sequence number 10 1628037531
060419 10:24:07 [Warning] mysql.user table is not updated to new password format; Disabling new password usage until mysql_fix_privilege_tables is run
060419 10:24:09 [Note] /usr/local/mysql/bin/mysqld: ready for connections.
Version: '5.0.20-pro'  socket: '/PATH/TO/SOCK/mysql.sock'  port: 3329  MySQL Pro (Commercial)
060419 10:24:09 [Note] Slave SQL thread initialized, starting replication in log 'logreplication.153' at position 28143237, relay log '/PATH/TO/RELAYLOG/relaylog.038738' position: 7915854
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=2097152
read_buffer_size=1044480
max_used_connections=0
max_connections=100
threads_connected=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 308847 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x8a966e8
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...
Cannot determine thread, fp=0xb3259bf4, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x81700e0
0xffffe420
0x8aa2844
0x8373938
0x820f452
0x81d696f
0x81bc7f5
0x81bc149
0x81b5f2a
0x81bc149
0x81b5f2a
0x81bbdfc
0x81b204d
0x81b2b8d
0x81d5b56
0x8184dca
0x818b416
0x81e26e3
0x81e2124
0x8248196
0x8245f2b
0xb7f97b63
0xb7ed018a
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do 
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x8a602a8 = update an, anparte Set Ap_Proprietario = 0 where An_Livro = "2" AND An_IdLivro = 42205 AND Ap_Anotacao = An_Id AND Ap_Proprietario = 1
thd->thread_id=2
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.

Number of processes running now: 0
060419 10:24:10  mysqld restarted
060419 10:24:10  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
060419 10:24:10  InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 10 1628037531.
InnoDB: Doing recovery: scanned up to log sequence number 10 1628037531
InnoDB: In a MySQL replication slave the last master binlog file
InnoDB: position 0 28141934, file name logreplication.153
060419 10:24:10  InnoDB: Started; log sequence number 10 1628037531
060419 10:24:10 [Warning] mysql.user table is not updated to new password format; Disabling new password usage until mysql_fix_privilege_tables is run
^X060419 10:24:12 [Note] /usr/local/mysql/bin/mysqld: ready for connections.
Version: '5.0.20-pro'  socket: '/PATH/TO/SOCK/mysql.sock'  port: 3329  MySQL Pro (Commercial)
060419 10:24:12 [Note] Slave SQL thread initialized, starting replication in log 'logreplication.153' at position 28143237, relay log '/PATH/TO/RELAYLOG/relaylog.038738' position: 7915854
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=2097152
read_buffer_size=1044480
max_used_connections=0
max_connections=100
threads_connected=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 308847 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x8a966e8
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...
Cannot determine thread, fp=0xb31b6bf4, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x81700e0
0xffffe420
0x8aa2844
0x8373938
0x820f452
0x81d696f
0x81bc7f5
0x81bc149
0x81b5f2a
0x81bc149
0x81b5f2a
0x81bbdfc
0x81b204d
0x81b2b8d
0x81d5b56
0x8184dca
0x818b416
0x81e26e3
0x81e2124
0x8248196
0x8245f2b
0xb7f0cb63
0xb7e4518a
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do 
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x8a602a8 = update an, anparte Set Ap_Proprietario = 0 where An_Livro = "2" AND An_IdLivro = 42205 AND Ap_Anotacao = An_Id AND Ap_Proprietario = 1
thd->thread_id=2
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.

####################################################################

How to repeat:
Starting replication.

Thank you for the bug report.
Have you followed the instruction for upgrading mentioned at?:

http://dev.mysql.com/doc/refman/5.0/en/upgrading-from-4-1.html

Otherwise can you try these instructions?

Thanks in advance.

I don't followed these instructions.
I'll try it and let you know.

Is there any problem upgrading my slave?! Because my masters will stay as 4.0 or 4.1 versions... (I have a server with many slaves)

Thank you

Thank you for the feedback. What you need to care is about the incompatible
changes, otherwise the slave will have problems with those queries. You can
see these incompatibles changes in the link I mentioned.

Gilberto,

please resolve the stack traces.

Heikki

Hi there!

Ok, here we go!

First one:
####################
0x81700e0 handle_segfault + 356
0xffffe420 _end + -140096144
0x8aa2844 _end + 5280148
0x8373938 heap_write + 88
0x820f452 _ZN7ha_heap9write_rowEPc + 66
0x81d696f _ZN12multi_update9send_dataER4ListI4ItemE + 179
0x81bc7f5 _Z8end_sendP4JOINP13st_join_tableb + 485
0x81bc149 _Z20evaluate_join_recordP4JOINP13st_join_tableiPc + 329
0x81b5f2a _Z10sub_selectP4JOINP13st_join_tableb + 178
0x81bc149 _Z20evaluate_join_recordP4JOINP13st_join_tableiPc + 329
0x81b5f2a _Z10sub_selectP4JOINP13st_join_tableb + 178
0x81bbdfc _Z9do_selectP4JOINP4ListI4ItemEP8st_tableP9Procedure + 268
0x81b204d _ZN4JOIN4execEv + 4121
0x81b2b8d _Z12mysql_selectP3THDPPP4ItemP13st_table_listjR4ListIS1_ES2_jP8st_orderSB_S2_SB_mP13select_resultP18st_select_lex_unitP13st_sel + 305
0x81d5b56 _Z18mysql_multi_updateP3THDP13st_table_listP4ListI4ItemES6_PS4_y15enum_duplicatesbP18st_select_lex_unitP13st_select_lex + 286
0x8184dca _Z21mysql_execute_commandP3THD + 3970
0x818b416 _Z11mysql_parseP3THDPcj + 306
0x81e26e3 _ZN15Query_log_event10exec_eventEP17st_relay_log_infoPKcj + 1467
0x81e2124 _ZN15Query_log_event10exec_eventEP17st_relay_log_info + 24
0x8248196 _Z20exec_relay_log_eventP3THDP17st_relay_log_info + 610
0x8245f2b handle_slave_sql + 999
0xb7f97b63 _end + -1348475725
0xb7ed018a _end + -1349293350
####################

Second one:
####################
0x81700e0 handle_segfault + 356
0xffffe420 _end + -140096144
0x8aa2844 _end + 5280148
0x8373938 heap_write + 88
0x820f452 _ZN7ha_heap9write_rowEPc + 66
0x81d696f _ZN12multi_update9send_dataER4ListI4ItemE + 179
0x81bc7f5 _Z8end_sendP4JOINP13st_join_tableb + 485
0x81bc149 _Z20evaluate_join_recordP4JOINP13st_join_tableiPc + 329
0x81b5f2a _Z10sub_selectP4JOINP13st_join_tableb + 178
0x81bc149 _Z20evaluate_join_recordP4JOINP13st_join_tableiPc + 329
0x81b5f2a _Z10sub_selectP4JOINP13st_join_tableb + 178
0x81bbdfc _Z9do_selectP4JOINP4ListI4ItemEP8st_tableP9Procedure + 268
0x81b204d _ZN4JOIN4execEv + 4121
0x81b2b8d _Z12mysql_selectP3THDPPP4ItemP13st_table_listjR4ListIS1_ES2_jP8st_orderSB_S2_SB_mP13select_resultP18st_select_lex_unitP13st_sel + 305
0x81d5b56 _Z18mysql_multi_updateP3THDP13st_table_listP4ListI4ItemES6_PS4_y15enum_duplicatesbP18st_select_lex_unitP13st_select_lex + 286
0x8184dca _Z21mysql_execute_commandP3THD + 3970
0x818b416 _Z11mysql_parseP3THDPcj + 306
0x81e26e3 _ZN15Query_log_event10exec_eventEP17st_relay_log_infoPKcj + 1467
0x81e2124 _ZN15Query_log_event10exec_eventEP17st_relay_log_info + 24
0x8248196 _Z20exec_relay_log_eventP3THDP17st_relay_log_info + 610
0x8245f2b handle_slave_sql + 999
0xb7f0cb63 _end + -1349045069
0xb7e4518a _end + -1349862694
####################

Please, check also if you'll get a crash after dumping tables in 4.0.x and restoring them in 5.0.20.

Hi, I already did that, you could take a look at: http://bugs.mysql.com/bug.php?id=19175

Thanx

Sorry, i misunderstand you, I'll do that and let you know them...

Hi Valeriy,

I've restored the dump from 4.0.18 to a 5.0.20 server without troubles.

Please let me know if there are other way for me to help...

Regards.

So, can you repeat a crash with same updates on 5.0.20 with restored dump? I am just trying to figure out the exact sequence of actions that leads to the crash.

Sure, I'll restore the dump to a 4.1.13 server, and update it to 5.0.20 to "re-crash", and after I'll let you know the results...

Please, reopen this bug report when you'll have any results with data restored on 5.0.20 from dump.

Ive restored the dump in a 5.0.20 server without crash, and/ar any troubles.

What I'll try to do is restore the dump in a 4.1.13 server, and them upgrade it to 5.0.20, following the upgrade steps, and without following (again, because that is what crashed the server).

> What I'll try to do is restore the dump in a 4.1.13 server, and them upgrade 
> it to 5.0.20, following the upgrade steps, and without following (again,
> because that is what crashed the server).

Have you got any results of the tests described above?

Sorry (again) for my late reply...
I coun't test it yet, there to much work here since the server's update...
But I'll see if I can get some results soon

Please, reopen this bug report when you'll get results.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".