Re: MPS: profiler

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, eller.helmut@gmail.com
> Date: Thu, 20 Jun 2024 20:29:42 +0000
> 
> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
> 0x00005555558b53d6 in PSEUDOVECTORP (a=0x7fffe6dde715, code=32) at 
> /home/yantar92/Git/emacs/src/lisp.h:1104
> 1104           && ((XUNTAG (a, Lisp_Vectorlike, union vectorlike_header)->size
> (gdb) bt
> #0  0x00005555558b53d6 in PSEUDOVECTORP (a=0x7fffe6dde715, code=32) at 
> /home/yantar92/Git/emacs/src/lisp.h:1104
> #1  0x00005555558b567f in CLOSUREP (a=0x7fffe6dde715) at 
> /home/yantar92/Git/emacs/src/lisp.h:3368
> #2  0x00005555558b5b80 in trace_hash (trace=0x555556329400, depth=16) at 
> profiler.c:189
> #3  0x00005555558b5eab in record_backtrace (plog=0x555555fd0960 <cpu>, 
> count=2) at profiler.c:291
> #4  0x00005555558b60fd in add_sample (plog=0x555555fd0960 <cpu>, count=2) at 
> profiler.c:353
> #5  0x00005555558b6153 in handle_profiler_signal (signal=27) at profiler.c:396
> #6  0x0000555555777704 in deliver_process_signal (sig=27, 
> handler=0x5555558b6104 <handle_profiler_signal>) at sysdep.c:1758
> #7  0x00005555558b6175 in deliver_profiler_signal (signal=27) at 
> profiler.c:402
> #8  0x00007ffff5855470 in <signal handler called> () at /lib64/libc.so.6
> #9  0x00007ffff5922d07 in mprotect () at /lib64/libc.so.6
> #10 0x000055555595c498 in ProtSet (base=0x7fffe2d86000, limit=<optimized 
> out>, mode=0) at protix.c:105
> #11 0x000055555594f7dd in shieldProtLower 
> (shield=shield@entry=0x7ffff7fc2700, seg=seg@entry=0x7fffe8001988, 
> mode=mode@entry=3) at shield.c:305
> #12 0x0000555555950417 in ShieldExpose (arena=arena@entry=0x7ffff7fc2000, 
> seg=seg@entry=0x7fffe8001988) at shield.c:737
> #13 0x000055555595f045 in amcSegFix (seg=0x7fffe8001988, ss=0x7fffffffa690, 
> refIO=0x7fffffffa0f8) at poolamc.c:1594
> #14 0x0000555555948d31 in SegFix (seg=0x7fffe8001988, ss=0x7fffffffa690, 
> refIO=0x7fffffffa0f8) at seg.c:793
> #15 0x00005555559550c0 in _mps_fix2 (mps_ss=0x7fffffffa698, 
> mps_ref_io=0x7fffffffa160) at trace.c:1433
> #16 0x00005555558b83af in fix_lisp_obj (ss=0x7fffffffa698, 
> pobj=0x7fffeb08b038) at igc.c:675
> #17 0x00005555558b86b5 in fix_array (ss=0x7fffffffa698, array=0x7fffeb08b038, 
> n=4) at igc.c:801
> #18 0x00005555558babf6 in fix_vectorlike (ss=0x7fffffffa698, 
> v=0x7fffeb08b030) at igc.c:1554
> #19 0x00005555558bc692 in fix_vector (ss=0x7fffffffa698, v=0x7fffeb08b030) at 
> igc.c:2086
> #20 0x00005555558ba757 in dflt_scan_obj (ss=0x7fffffffa698, 
> base_start=0x7fffeb08b028, base_limit=0x7fffeb08c608, closure=0x0) at 
> igc.c:1481
> #21 0x00005555558baac4 in dflt_scanx (ss=0x7fffffffa698, 
> base_start=0x7fffeb08b000, base_limit=0x7fffeb08c608, closure=0x0) at 
> igc.c:1531
> #22 0x00005555558bab63 in dflt_scan (ss=0x7fffffffa698, 
> base_start=0x7fffeb08b000, base_limit=0x7fffeb08c608) at igc.c:1542
> #23 0x000055555595568f in TraceScanFormat (ss=ss@entry=0x7fffffffa690, 
> base=base@entry=0x7fffeb08b000, limit=limit@entry=0x7fffeb08c608) at 
> trace.c:1539
> #24 0x000055555595f609 in amcSegScan (totalReturn=0x7fffffffa68c, 
> seg=0x7fffe8289870, ss=0x7fffffffa690) at poolamc.c:1427
> #25 0x0000555555948c6f in SegScan 
> (totalReturn=totalReturn@entry=0x7fffffffa68c, seg=seg@entry=0x7fffe8289870, 
> ss=ss@entry=0x7fffffffa690) at seg.c:775
> #26 0x0000555555954ae1 in traceScanSegRes (ts=ts@entry=1, rank=rank@entry=1, 
> arena=arena@entry=0x7ffff7fc2000, seg=seg@entry=0x7fffe8289870) at 
> trace.c:1205
> #27 0x0000555555954beb in traceScanSeg (ts=ts@entry=1, rank=1, 
> arena=arena@entry=0x7ffff7fc2000, seg=seg@entry=0x7fffe8289870) at 
> trace.c:1267
> #28 0x0000555555954d63 in TraceSegAccess (arena=arena@entry=0x7ffff7fc2000, 
> seg=seg@entry=0x7fffe8289870, mode=mode@entry=1) at trace.c:1320
> #29 0x000055555594959b in SegWholeAccess (seg=0x7fffe8289870, 
> arena=0x7ffff7fc2000, addr=0x7fffeb08c590, mode=1, context=0x7fffffffa8d0) at 
> seg.c:1262
> #30 0x0000555555948309 in SegAccess
>     (seg=0x7fffe8289870, arena=arena@entry=0x7ffff7fc2000, 
> addr=addr@entry=0x7fffeb08c590, mode=1, context=context@entry=0x7fffffffa8d0) 
> at seg.c:723
> #31 0x0000555555928f51 in ArenaAccess (addr=0x7fffeb08c590, mode=<optimized 
> out>, mode@entry=3, context=context@entry=0x7fffffffa8d0) at global.c:671
> #32 0x000055555595c6e2 in sigHandle (sig=<optimized out>, 
> info=0x7fffffffabf0, uap=0x7fffffffaac0) at protsgix.c:97
> #33 0x00007ffff5855470 in <signal handler called> () at /lib64/libc.so.6
> #34 0x00005555558a1dd8 in copy_intervals (tree=0x7fffe651f500, start=587977, 
> length=11) at intervals.c:2247

This tells that we got SIGPROF while inside MPS code, in its sigHandle
handler for SIGSEGV caused by protection violation.  Does something
special happens on GNU/Linux when a nested signal is delivered,
i.e. when a signal is delivered when the program is in a signal
handler?  Some special small stack, perhaps?

Also, can 'static struct profiler_log cpu', which is being worked on
by record_backtrace, be affected by MPS in any way?

Ihor, can you show the data involved in this segfault, i.e. trace[i]
which is the argument of CLOSUREP that segfaults?  And in general all
the data inside trace_hash.  You'll need to "source .gdbinit" to be
able to show Lisp data in human-readable format.