Slave servers during upgrade should be started with --skip-slave-start in addition to skip grant
https://dev.mysql.com/doc/refman/5.6/en/replication-upgrade.html

Before upgrade, make a clean shutdown, if you have orphan tables, drop it before upgrade: https://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting-datadict.html

I'm able to reproduce your crash with percona server 5.5.57-38.9 to 5.6.37-82.2 upgrade.

docker run  -it -e MYSQL_ALLOW_EMPTY_PASSWORD=1 \
 --name lp1719284 --entrypoint=/bin/bash percona:5.5

mysql_install_db; chown -R /var/lib/mysql
mysql -e 'create database if not exists test; create temporary table test.t(c int) engine=innodb;select sleep(100)' &
sleep 5
kill -9 $(pgrep -xn mysqld_safe) $(pgrep -xn mysqld)
cp -ap /var/lib/mysql /var/lib/mysql1/
rm -rf /var/lib/mysql/*
apt-get install -y percona-server-5.6
rm -rf /var/lib/mysql/*
cp -ap /var/lib/mysql1/* /var/lib/mysql/
mysqld_safe --skip-grant-tables

2017-10-04 05:39:40 7fd461df1740  InnoDB: Assertion failure in thread 140550151804736 in file pars0pars.cc line 865
InnoDB: Failing assertion: sym_node->table != NULL
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
05:39:40 UTC - mysqld got signal 6 ;
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.
Please help us make Percona Server better by reporting any
bugs at http://bugs.percona.com/

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

Thread pointer: 0x0
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 = 0 thread_stack 0x30000
0x8c42fc my_print_stacktrace + 44
0x64b939 handle_fatal_signal + 1129
0x7fd4619d1890 _end + 1617425736
0x7fd45f957067 _end + 1583369503
0x7fd45f958448 _end + 1583374592
0x99503f pars_update_statement(upd_node_t*, sym_node_t*, void*) + 1663
0xad237e yyparse() + 2462
0x996a5f pars_sql(pars_info_t*, char const*) + 143
0x99a906 que_eval_sql(pars_info_t*, char const*, unsigned long, trx_t*) + 70
0x9c1487 row_drop_table_for_mysql(char const*, trx_t*, bool, bool) + 1975
0x9c3512 row_mysql_drop_temp_tables() + 1474
0x96eb8e recv_recovery_rollback_active() + 46
0x9eafae innobase_start_or_create_for_mysql() + 10974
0x926eb7 innobase_init(void*) + 2823
0x592318 ha_initialize_handlerton(st_plugin_int*) + 72
0x6d5981 plugin_initialize(st_plugin_int*) + 97
0x6dc572 plugin_init(int*, char**, int) + 2306
0x58a2c7 init_server_components() + 1111
0x58b313 mysqld_main(int, char**) + 1027
0x7fd45f943b45 _end + 1583290365
0x57d9ed _start + 41