MySQL Bugs: #79243: 0xc0000005

Bug #79243	0xc0000005
Submitted:	12 Nov 2015 0:56	Modified:	5 Oct 2017 13:12
Reporter:	Richard Browne	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Server: DML	Severity:	S2 (Serious)
Version:	5.7.9	OS:	Windows (10 x64)
Assigned to:		CPU Architecture:	Any
Tags:	crash, exception 0xc0000005

Description:
We are experiencing a MySQL server crash daily. The stack trace will be attached. It's the same every time - in function copy_blob_value. It seems to happen always when executing the same insert.

How to repeat:
Unknown

Exception details from MySQL server log

Attachment: exception 0xc0000005.txt (text/plain), 3.26 KiB.

Thank you for the bug report. Are you able to repeat the crash with the query printed in the call stack:

Query (78b2df5c80): INSERT INTO SubjectExtras (SubjectID,FieldID,TextValue,IntegerValue,FloatValue,DateValue,BlobValue) VALUES ('1389625','2079','Infant - Toddlers',NULL,NULL,NULL,NULL) ON DUPLICATE KEY UPDATE TextValue=VALUES(TextValue),IntegerValue=VALUES(IntegerValue),FloatValue=VALUES(FloatValue),DateValue=VALUES(DateValue),BlobValue=VALUES(BlobValue)

If yes please provide a test case with create table statement and insert data?. Thanks.

Hi. We have manually executed the insert statement from Workbench and it didn't crash. So unfortunately it's not that simple.

Also I should mention this is Windows 10.

Thank you for the feedback. Anyway are you able to provide (private if you wish) a dump file of the offended tables? and my.ini file too. Thanks.

Some further information. We've had a second site report the same crash in MySQL 5.7.9. Also happening daily. The insert statement in this case is for a different table.

I'm afraid I can't offer much else. We've downgraded to MySQL 5.6 and the problem has gone away.

I've a customer hitting the exact same problem. They are using 5.7 in RDS.

This is the stacktrace: 

Thread pointer: 0x2b3da0090000
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 = 2b39fd335e80 thread_stack 0x40000
/rdsdbbin/mysql/bin/mysqld(my_print_stacktrace+0x2c)[0xe9361c]
/rdsdbbin/mysql/bin/mysqld(handle_fatal_signal+0x451)[0x78ddd1]
/lib64/libpthread.so.0(+0xf5b0)[0x2b39fd5b35b0]
/rdsdbbin/mysql/bin/mysqld(_ZN10Field_blob15copy_blob_valueEP11st_mem_root+0x28)[0x7ba498]
/rdsdbbin/mysql/bin/mysqld(_Z25mysql_prepare_blob_valuesP3THDR4ListI4ItemEP11st_mem_root+0x298)[0xde42b8]
/rdsdbbin/mysql/bin/mysqld(_Z12write_recordP3THDP5TABLEP9COPY_INFOS4_+0x85d)[0xde4e4d]
/rdsdbbin/mysql/bin/mysqld(_ZN14Sql_cmd_insert12mysql_insertEP3THDP10TABLE_LIST+0x95f)[0xde59ef]
/rdsdbbin/mysql/bin/mysqld(_ZN14Sql_cmd_insert7executeEP3THD+0xc3)[0xde6133]
/rdsdbbin/mysql/bin/mysqld(_Z21mysql_execute_commandP3THDb+0x5b0)[0xc73df0]
/rdsdbbin/mysql/bin/mysqld(_ZN18Prepared_statement7executeEP6Stringb+0x35d)[0xca262d]
/rdsdbbin/mysql/bin/mysqld(_ZN18Prepared_statement12execute_loopEP6StringbPhS2_+0xca)[0xca2a1a]
/rdsdbbin/mysql/bin/mysqld(_Z19mysqld_stmt_executeP3THDmmPhm+0xe4)[0xca2cf4]
/rdsdbbin/mysql/bin/mysqld(_Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command+0x1403)[0xc7b6f3]
/rdsdbbin/mysql/bin/mysqld(_Z10do_commandP3THD+0x177)[0xc7c4f7]
/rdsdbbin/mysql/bin/mysqld(handle_connection+0x278)[0xd34438]
/rdsdbbin/mysql/bin/mysqld(pfs_spawn_thread+0x18f)[0x11f4aff]
/lib64/libpthread.so.0(+0x7f18)[0x2b39fd5abf18]
/lib64/libc.so.6(clone+0x6d)[0x2b39fe8fdb2d]

The table ends like this:

  `metadata` text,
  `last_updated` datetime NOT NULL,

but the insert is done like this from the stacktrace (we don't see the end):

INSERT INTO  blablabla (... ,`last_updated`,`metadata`) VALUES (..., '2016-04-29 02:32:01', '{\"flags\":4,\"xxxx\":\"0001-01-01T00:00:00Z\",\"yyyy\":\"0001-01-01T00:

When the query is run in mysql client it works, every time the application runs it, it crash.

I experienced this behavior also in 5.7.13 (x64) on a Windows Server 2012 R2 machine.

Seeing the same error on MySQL 5.7.16 and CentOS 7.2

@@[17 Nov 18:11] Owen Owen

Seeing the same error on MySQL 5.7.16 and CentOS 7.2

Are you able to provide a repeatable test case (create table, insert data , query). Thanks in advance.

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

Encountered the same, 
Looks like a memory allocation issue at:

mysql-5.7.16.R1/sql/field.h:3802

This also happens to us now after upgrade from 5.6.35 to 5.7.19 on both debiam 7.9 and debian 8.1:

09:21:07 UTC - 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.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.

key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=107
max_threads=1024
thread_count=30
connection_count=28
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 8541536 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7f2bd0000ae0
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 = 7f2d6d4ace80 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x2c)[0xe86e2c]
/usr/sbin/mysqld(handle_fatal_signal+0x459)[0x7ab4b9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf890)[0x7f3a14308890]
/usr/sbin/mysqld(_ZN10Field_blob15copy_blob_valueEP11st_mem_root+0x25)[0x7d9075]
/usr/sbin/mysqld(_Z25mysql_prepare_blob_valuesP3THDR4ListI4ItemEP11st_mem_root+0x3ac)[0xdcc98c]
/usr/sbin/mysqld(_Z12write_recordP3THDP5TABLEP9COPY_INFOS4_+0x9a3)[0xdcef83]
/usr/sbin/mysqld(_ZN14Sql_cmd_insert12mysql_insertEP3THDP10TABLE_LIST+0x818)[0xdcf9c8]
/usr/sbin/mysqld(_ZN14Sql_cmd_insert7executeEP3THD+0xc2)[0xdd01d2]
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THDb+0x68b)[0xc566ab]
/usr/sbin/mysqld(_Z11mysql_parseP3THDP12Parser_state+0x3bd)[0xc5b4cd]
/usr/sbin/mysqld(_Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command+0x932)[0xc5be72]
/usr/sbin/mysqld(_Z10do_commandP3THD+0x18f)[0xc5d68f]
/usr/sbin/mysqld(handle_connection+0x270)[0xd1af60]
/usr/sbin/mysqld(pfs_spawn_thread+0x1b4)[0xe9e894]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8064)[0x7f3a14301064]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f3a12dc462d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f2bd0005510): INSERT INTO contact_snapshot_v2     (instance_id, contact_id, last_activity_date, last_activity_type, last_activity_info, last_activity_source, site_user_type)     VALUES (x'A2555B861BE64D278D599D75A5FB6D6C', x'F13F5C6B6090450A9FAFDDA91BD0456D', '
2017-08-31 09:21:05.085', 'messaging/im', '{"activityId":"14dfe3cb-d32c-a9a2-78a0-163c76c6c681","activityStreamId":"f13f5c6b-6090-450a-9faf-dda91bd0456d","activityType":"messaging/im","dateCreated":"2017-08-31T09:21:05.085Z","activityLocationUrl":null,"activityDetails"
:null,"activityInfo":{"type":"CHAT","content":[{"direction":"CUSTOMER_TO_BUSINESS","time":"2017-08-31T09:21:05.085Z","message":"Dame el n  mero de cuenta q te hago el ingreso de 4.90","media":null}],"threadId":"f13f5c6b-6090-450a-9faf-dda91bd0456d","metaData":[]},"sour
ceId":"14517e1a-3ff0-af98-408e-2bd6953c36a2","initiatorId":null}', '14517e1a-3ff0-af98-408e-2bd6953c36a2', 'Contact')     ON DUPLICATE KEY UPDATE contact_id = x'F13F5C6B6090450A9FAFDDA91BD0456D', last_activity_date = '2017-08-31 09:21:05.0
Connection ID (thread ID): 73
Status: NOT_KILLED

This is also the same case as mentioned here, in the mysql client utility locally on the mysql server the statement works, but from the app it crashes the DB.

BTW the table definition is:

CREATE TABLE `contact_snapshot_v2` (
  `instance_id` binary(16) NOT NULL,
  `contact_id` binary(16) NOT NULL,
  `last_activity_date` timestamp(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3),
  `last_activity_type` varchar(100) NOT NULL 
  `last_activity_info` blob,
  `last_activity_source` varchar(100) DEFAULT NULL,
  `site_user_type` varchar(100) NOT NULL DEFAULT 'Contact' ,
  `merged_into_contact_id` binary(16) DEFAULT NULL,
  PRIMARY KEY (`instance_id`,`contact_id`),
  KEY `contacts_by_datetime` (`instance_id`,`last_activity_date`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=16;

Any update on that ? 
It looks like we bumped into this violent bug that crashes our upgraded mysql 5.7 DB.
Any solution/workaround for this issue?

Hi,

Any update on this? This affects me.

Also hit this on an INSERT query:

Demangeled stacktrace:
/usr/sbin/mysqld(my_print_stacktrace+0x3b)[0xef7bcb]
/usr/sbin/mysqld(handle_fatal_signal+0x461)[0x7aff11]
/lib64/libpthread.so.0(+0xf5e0)[0x7f12da2385e0]
/lib64/libc.so.6(+0x142e40)[0x7f12d8d37e40]
/usr/sbin/mysqld(Field_blob::copy_blob_value(st_mem_root*)+0x84)[0x7de9f4]
/usr/sbin/mysqld(mysql_prepare_blob_values(THD*, List<Item>&, st_mem_root*)+0x2b8)[0xe3f9d8]
/usr/sbin/mysqld(write_record(THD*, TABLE*, COPY_INFO*, COPY_INFO*)+0x9c0)[0xe406e0]
/usr/sbin/mysqld(Sql_cmd_insert::mysql_insert(THD*, TABLE_LIST*)+0x82d)[0xe4115d]
/usr/sbin/mysqld(Sql_cmd_insert::execute(THD*)+0xe6)[0xe419b6]
/usr/sbin/mysqld(mysql_execute_command(THD*, bool)+0x5d0)[0xcc2e90]
/usr/sbin/mysqld(mysql_parse(THD*, Parser_state*)+0x3b5)[0xcc9265]
/usr/sbin/mysqld(dispatch_command(THD*, COM_DATA const*, enum_server_command)+0xa7a)[0xcc9d5a]
/usr/sbin/mysqld(do_command(THD*)+0x19f)[0xccb79f]
/usr/sbin/mysqld(handle_connection+0x288)[0xd8ad38]
/usr/sbin/mysqld(pfs_spawn_thread+0x1b4)[0x126de04]
/lib64/libpthread.so.0(+0x7e25)[0x7f12da230e25]
/lib64/libc.so.6(clone+0x6d)[0x7f12d8ced34d]

There have been fixes relating to this in 5.7.19+:

"Noted in 5.7.19, 8.0.2 changelogs.

Incorrect behavior could occur for INSERT statements executed in
stored-program or prepared-statement context, if the VALUES part of
an ON DUPLICATE KEY UPDATE clause referred to a BLOB value in the
INSERT column list. "

However, once updating to 5.7.19 you may see another similar crash, that is internally filed, and I'll mark this as a duplicate of it so it is updated when fix is available.

Related fixed in 5.7.21, 8.0.4:

Following an INSERT statement with BLOB values in the ON DUPLICATE
KEY UPDATE clause that failed with a constraint violation, a similar
statement with no reason to return an error could cause a server
exit.

Thank you, Paul and Shane, for the update.

Can you also please let us know when this fix or version 5.7.21 is going to be released?

Hi,

Any updates?

Issue resolved with Release of 5.7.21.
Thanks.

Just FYI - We checked on new 5.7.21 community edition and failed again.
The issue was NOT fixed for us.

Thanks,
Eyal

If you're seeing this bug in 5.7.21, there was another fix in 5.7.22...