Switching back from a fiber with an exception could point to an invalid PC.
The investigation was inspired by #6060.
I could not create code to reproduce the problem.
But before this patch, I got the following results on my experimental branch of ngx_mruby.
mruby is built with conf.enable_debug.
Process 63755 stopped
* thread #1, name = 'nginx', stop reason = signal SIGABRT
frame #0: 0x0000000826985c5a libc.so.7`__sys_thr_kill + 10
libc.so.7`__sys_thr_kill:
-> 0x826985c5a <+10>: jb 0x826983db8
0x826985c60 <+16>: retq
0x826985c61: int3
0x826985c62: int3
(lldb) bt
* thread #1, name = 'nginx', stop reason = signal SIGABRT
* frame #0: 0x0000000826985c5a libc.so.7`__sys_thr_kill + 10
frame #1: 0x00000008268fe6d4 libc.so.7`__raise + 52
frame #2: 0x00000008269afa59 libc.so.7`abort + 73
frame #3: 0x00000008268e14c1 libc.so.7`__assert + 81
frame #4: 0x000000000049eea3 nginx`catch_handler_find(mrb=0x00000008282e9000, ci=0x000000082831b000, pc="8\U00000001i\U0000001d\U00000002", filter=3) at vm.c:1117:3
frame #5: 0x00000000004a48ec nginx`mrb_vm_exec(mrb=0x00000008282e9000, proc=0x00000008283c3aa0, pc="8\U00000001i\U0000001d\U00000002") at vm.c:2201:22
frame #6: 0x00000000004eb9cd nginx`fiber_switch(mrb=0x00000008282e9000, self=(w = 35034770816), len=0, a=0x0000000000000000, resume=true, vmexec=true) at fiber.c:278:13
frame #7: 0x00000000004ebaa0 nginx`mrb_fiber_resume(mrb=0x00000008282e9000, fib=(w = 35034770816), len=0, a=0x0000000000000000) at fiber.c:319:10
frame #8: 0x0000000000461f4f nginx`ngx_mrb_run_fiber(mrb=0x00000008282e9000, fiber_proc=0x0000000828253530, result=0x0000000828267ff8) at ngx_http_mruby_async.c:74:19
frame #9: 0x0000000000461e8c nginx`ngx_mrb_start_fiber(r=0x0000000828267050, mrb=0x00000008282e9000, rproc=0x00000008283c3aa0, result=0x0000000828267ff8) at ngx_http_mruby_async.c:60:10
frame #10: 0x0000000000452244 nginx`ngx_mrb_run(r=0x0000000828267050, state=0x00000008282d5e00, code=0x00000008283d3b30, cached=1, result=0x0000000000000000) at ngx_http_mruby_module.c:842:7
frame #11: 0x0000000000451be6 nginx`ngx_http_mruby_content_inline_handler(r=0x0000000828267050) at ngx_http_mruby_module.c:1582:1
frame #12: 0x00000000003995c2 nginx`ngx_http_core_content_phase(r=0x0000000828267050, ph=0x000000082a501410) at ngx_http_core_module.c:1268:10
frame #13: 0x0000000000397c8c nginx`ngx_http_core_run_phases(r=0x0000000828267050) at ngx_http_core_module.c:875:14
frame #14: 0x0000000000397c07 nginx`ngx_http_handler(r=0x0000000828267050) at ngx_http_core_module.c:858:5
frame #15: 0x00000000003a9cee nginx`ngx_http_process_request(r=0x0000000828267050) at ngx_http_request.c:2127:5
frame #16: 0x00000000003abde9 nginx`ngx_http_process_request_headers(rev=0x000000082a559e60) at ngx_http_request.c:1529:13
frame #17: 0x00000000003ab337 nginx`ngx_http_process_request_line(rev=0x000000082a559e60) at ngx_http_request.c:1196:13
frame #18: 0x00000000003a6558 nginx`ngx_http_wait_request_handler(rev=0x000000082a559e60) at ngx_http_request.c:523:5
frame #19: 0x000000000037f151 nginx`ngx_kqueue_process_events(cycle=0x00000008282c0dd0, timer=60000, flags=1) at ngx_kqueue_module.c:669:9
frame #20: 0x000000000036c3c3 nginx`ngx_process_events_and_timers(cycle=0x00000008282c0dd0) at ngx_event.c:248:12
frame #21: 0x000000000037bd52 nginx`ngx_single_process_cycle(cycle=0x00000008282c0dd0) at ngx_process_cycle.c:300:9
frame #22: 0x00000000003309fc nginx`main(argc=1, argv=0x0000000820921728) at nginx.c:381:9
frame #23: 0x0000000000330270 nginx`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1_c.c:75:7