Fixed unwinding block that could point to invalid PC

[dearblue]

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

[dearblue]

The cause is my #5843.
🙇

When jumping from inside a L_RAISE block to a L_RAISE label, the pc variable was not updated.