# MySQL 5.7.17-11 and 5.7.16-10 crashing after upgrade from MySQL 5.6

**URL:** https://forums.percona.com/t/mysql-5-7-17-11-and-5-7-16-10-crashing-after-upgrade-from-mysql-5-6/5451
**Category:** Other MySQL® Questions
**Created:** [February 27, 2017, 10:13pm UTC](https://forums.percona.com/t/mysql-5-7-17-11-and-5-7-16-10-crashing-after-upgrade-from-mysql-5-6/5451 "2017-02-27T22:13:43Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![krishyadav](https://avatars.discourse-cdn.com/v4/letter/k/eb8c5e/32.png) [@krishyadav](https://forums.percona.com/u/krishyadav)
#### Post date: [February 27, 2017, 10:13pm UTC](https://forums.percona.com/t/mysql-5-7-17-11-and-5-7-16-10-crashing-after-upgrade-from-mysql-5-6/5451/1 "2017-02-27T22:13:43Z")

</div>

We successfully upgraded Percona MySQL server version 5.6.29-76.2 to 5.7.16-10 (first) but it was crashing then we upgraded to 5.7.17-11. We see 5.7.17-11 is also crashing.  
So far we are not able to figure out anything except that there is something to do with lob/text data.  
Following is error and stack trace.

00:01:39 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.  
Please help us make Percona Server better by reporting any  
bugs at [URL][System Dashboard - Percona JIRA](http://bugs.percona.com/%5B/URL%5D)

key\_buffer\_size=268435456  
read\_buffer\_size=1048576  
max\_used\_connections=417  
max\_threads=1001  
thread\_count=408  
connection\_count=406  
It is possible that mysqld could use up to  
key\_buffer\_size + (read\_buffer\_size + sort\_buffer\_size)\*max\_threads = 1556244 K bytes of memory  
Hope that’s ok; if not, decrease some variables in the equation.

Thread pointer: 0x7ef95c03c880  
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 = 7ef8e6df7d40 thread\_stack 0x40000  
/usr/sbin/mysqld(my\_print\_stacktrace+0x2c)[0xed056c]  
/usr/sbin/mysqld(handle\_fatal\_signal+0x461)[0x7a0631]  
/lib64/libpthread.so.0[0x31d080f7e0]  
/usr/sbin/mysqld(\_ZN10Field\_blob15copy\_blob\_valueEP11st\_mem\_root+0x28)[0x7e3d08]  
/usr/sbin/mysqld(\_Z25mysql\_prepare\_blob\_valuesP3THDR4ListI4ItemEP11st\_mem\_root+0x2b8)[0xe1b468]  
/usr/sbin/mysqld(_Z12write\_recordP3THDP5TABLEP9COPY\_INFOS4_+0x87d)[0xe1c02d]  
/usr/sbin/mysqld(\_ZN14Sql\_cmd\_insert12mysql\_insertEP3THDP10TABLE\_LIST+0x82d)[0xe1ca9d]  
/usr/sbin/mysqld(\_ZN14Sql\_cmd\_insert7executeEP3THD+0xc2)[0xe1d2d2]  
/usr/sbin/mysqld(\_Z21mysql\_execute\_commandP3THDb+0x18d7)[0xca9e67]  
/usr/sbin/mysqld(\_ZN18Prepared\_statement7executeEP6Stringb+0x357)[0xcd9e57]  
/usr/sbin/mysqld(_ZN18Prepared\_statement12execute\_loopEP6StringbPhS2_+0xca)[0xcda25a]  
/usr/sbin/mysqld(\_Z19mysqld\_stmt\_executeP3THDmmPhm+0x13b)[0xcda58b]  
/usr/sbin/mysqld(\_Z16dispatch\_commandP3THDPK8COM\_DATA19enum\_server\_command+0x190f)[0xcb197f]  
/usr/sbin/mysqld(\_Z10do\_commandP3THD+0x1b7)[0xcb24a7]  
/usr/sbin/mysqld(handle\_connection+0x2a0)[0xd76740]  
/usr/sbin/mysqld(pfs\_spawn\_thread+0x1b4)[0xeed474]  
/lib64/libpthread.so.0[0x31d0807aa1]  
/lib64/libc.so.6(clone+0x6d)[0x31d00e8aad]

Trying to get some variables.  
Some pointers may be invalid and cause the dump to abort.  
Query (7ef95c12bec0): is an invalid pointer  
Connection ID (thread ID): 4170  
Status: NOT\_KILLED

After converting it in readable format then we see this.

0xed056c my\_print\_stacktrace + 44  
0x7a0631 handle\_fatal\_signal + 1121  
0x31d080f7e0 \_end + -829069216  
0x7e3d08 Field\_blob::copy\_blob\_value(st\_mem\_root\*) + 40  
0xe1b468 mysql\_prepare\_blob\_values(THD\*, List&, st\_mem\_root\*) + 696  
0xe1c02d write\_record(THD\*, TABLE\*, COPY\_INFO\*, COPY\_INFO\*) + 2173  
0xe1ca9d Sql\_cmd\_insert::mysql\_insert(THD\*, TABLE\_LIST\*) + 2093  
0xe1d2d2 Sql\_cmd\_insert::execute(THD\*) + 194  
0xca9e67 mysql\_execute\_command(THD\*, bool) + 6359  
0xcd9e57 Prepared\_statement::execute(String\*, bool) + 855  
0xcda25a Prepared\_statement::execute\_loop(String\*, bool, unsigned char\*, unsigned char\*) + 202  
0xcda58b mysqld\_stmt\_execute(THD\*, unsigned long, unsigned long, unsigned char\*, unsigned long) + 315  
0xcb197f dispatch\_command(THD\*, COM\_DATA const\*, enum\_server\_command) + 6415  
0xcb24a7 do\_command(THD\*) + 439  
0xd76740 handle\_connection + 672  
0xeed474 pfs\_spawn\_thread + 436  
0x31d0807aa1 \_end + -829101279  
0x31d00e8aad \_end + -836568275

When we read stack trace from bottom to top then we can see that MySQL is working on some record which has something to do with blob data.

Has someone faced the same issue?

I have also filed a bug [url][https://bugs.launchpad.net/percona-server/+bug/1667552[/url]](https://bugs.launchpad.net/percona-server/+bug/1667552%5B/url%5D) but so far no response.

Any pointer/clue highly appreciated.

Thanks