Perf doesn’t help. Perf only shows a sampling over time (eg where the cpu has spent) and as you see in the logs it doesn’t work for pre-existing threads.
You need to figure out how to generate a core dump. When you go process dies does the system function as normal? > On Oct 31, 2022, at 11:52 AM, Steven Sokol <st...@stevensokol.com> wrote: > > Ok, here's what perf shows: > > root@pi4cm1(rw):/# perf record -a -g sleep 5 > Reading /proc/4199/task/4199/maps time out. You may want to increase the time > limit by --proc-map-timeout > [ perf record: Woken up 8 times to write data ] > Warning: > 1 map information files for pre-existing threads were > not processed, if there are samples for addresses they > will not be resolved, you may find out which are these > threads by running with -v and redirecting the output > to a file. > The time limit to process proc map is too short? > Increase it by --proc-map-timeout > [ perf record: Captured and wrote 6.510 MB perf.data (80088 samples) ] > > > > ┌─Warning:─────────────────────────────────────────────┐ > │1 map information files for pre-existing threads were │ > │not processed, if there are samples for addresses they│ > │will not be resolved, you may find out which are these│ > │threads by running with -v and redirecting the output │ > │to a file. │ > │The time limit to process proc map is too short? │ > │Increase it by --proc-map-timeout │ > │ │ > │ │ > │Press any key... │ > └──────────────────────────────────────────────────────┘ > > > > Samples: 80K of event 'cpu-clock:pppH', Event count (approx.): 20022000000 > Children Self Command Shared Object Symbol > + 41.96% 0.00% fvUnisocket [vectors] [.] > 0xffff0fc0 > + 41.65% 41.65% fvUnisocket [vectors] [.] > 0x00000fc0 > + 30.14% 29.94% fvUnisocket fvUnisocket [.] kernelcas > + 5.05% 0.00% fvUnisocket [vectors] [.] > 0xffff0fa0 > + 5.04% 5.01% fvUnisocket fvUnisocket [.] > runtime/internal/atomic.Cas > + 5.01% 5.01% fvUnisocket [vectors] [.] > 0x00000fa0 > + 4.56% 4.53% fvUnisocket fvUnisocket [.] > runtime/internal/atomic.goLoad64 > + 2.97% 0.00% fvUnisocket [vectors] [.] > 0xffff0fd8 > + 2.95% 2.95% fvUnisocket [vectors] [.] > 0x00000fd8 > + 2.52% 0.00% fvUnisocket [vectors] [.] > 0xffff0fcc > + 2.50% 2.50% fvUnisocket [vectors] [.] > 0x00000fcc > + 2.26% 0.00% swapper [kernel.kallsyms] [k] > cpu_startup_entry > + 2.25% 0.00% swapper [kernel.kallsyms] [k] do_idle > + 2.12% 0.00% swapper [kernel.kallsyms] [k] > default_idle_call > + 2.09% 2.09% swapper [kernel.kallsyms] [k] > arch_cpu_idle > + 1.74% 0.00% swapper [unknown] [k] > 0x002018ac > + 1.74% 0.00% swapper [kernel.kallsyms] [k] > secondary_start_kernel > + 1.48% 1.47% fvUnisocket fvUnisocket [.] cas > + 1.19% 1.19% fvUnisocket fvUnisocket [.] > runtime/internal/atomic.goStore64 > 0.96% 0.95% dump1090 dump1090 [.] > convert_uc8_nodc_nopower > + 0.65% 0.00% fvUnisocket [kernel.kallsyms] [k] __irq_usr > + 0.65% 0.00% fvUnisocket [kernel.kallsyms] [k] > gic_handle_irq > + 0.65% 0.00% fvUnisocket [kernel.kallsyms] [k] > __handle_domain_irq > + 0.65% 0.00% fvUnisocket [kernel.kallsyms] [k] irq_exit > 0.65% 0.17% fvUnisocket [kernel.kallsyms] [k] > __softirqentry_text_start > + 0.52% 0.00% swapper [kernel.kallsyms] [k] > start_kernel > + 0.52% 0.00% swapper [kernel.kallsyms] [k] > arch_call_rest_init > + 0.52% 0.00% swapper [kernel.kallsyms] [k] > __noinstr_text_end > 0.38% 0.02% fvUnisocket [kernel.kallsyms] [k] > tasklet_action_common.constprop.4 > 0.38% 0.00% fvUnisocket [kernel.kallsyms] [k] > tasklet_hi_action > 0.36% 0.05% fvUnisocket [kernel.kallsyms] [k] > usb_giveback_urb_bh > 0.31% 0.00% fvUnisocket [kernel.kallsyms] [k] > __usb_hcd_giveback_urb > 0.29% 0.00% fvUnisocket [uvcvideo] [k] > uvc_video_complete > 0.26% 0.00% swapper [ipv6].rodata.str1.4 [k] .LC0 > 0.24% 0.00% swapper [ipv6]_ftrace_events [k] > __event_fib6_table_lookup+0x0 > 0.19% 0.00% perf_5.10 [kernel.kallsyms] [k] > __ret_fast_syscall > 0.18% 0.00% perf_5.10 [unknown] [k] 00000000 > 0.18% 0.00% perf_5.10 libpthread-2.28.so [.] > __libc_write > 0.18% 0.00% perf_5.10 [kernel.kallsyms] [k] > __se_sys_write > 0.18% 0.00% perf_5.10 [kernel.kallsyms] [k] > ksys_write > 0.17% 0.00% perf_5.10 [kernel.kallsyms] [k] vfs_write > 0.17% 0.00% perf_5.10 [kernel.kallsyms] [k] > ext4_file_write_iter > 0.17% 0.00% perf_5.10 [kernel.kallsyms] [k] > ext4_buffered_write_iter > 0.17% 0.00% perf_5.10 [kernel.kallsyms] [k] > generic_perform_write > 0.17% 0.00% fvUnisocket [uvcvideo] [k] > uvc_video_decode_isoc > 0.17% 0.17% fvUnisocket [uvcvideo] [k] > uvc_video_decode_start > 0.15% 0.15% fvUnisocket [kernel.kallsyms] [k] > _raw_spin_unlock_irqrestore > 0.14% 0.00% dump1090 [unknown] [.] > 0x807f7e7f > 0.12% 0.00% redis-server [kernel.kallsyms] [k] > __ret_fast_syscall > 0.12% 0.00% dump1090 [unknown] [.] > 0x80808180 > 0.11% 0.00% dump1090 [unknown] [.] > 0x81807e7f > 0.11% 0.00% dump1090 [unknown] [.] > 0x7e7f8080 > 0.11% 0.00% dump1090 [unknown] [.] > 0x807e817e > 0.11% 0.00% dump1090 [unknown] [.] > 0x80817f80 > 0.10% 0.00% dump1090 [unknown] [.] > 0x807e7f7f > 0.10% 0.00% fvLogger [unknown] [k] 00000000 > 0.10% 0.00% redis-server [unknown] [.] > 0x00000011 > 0.09% 0.09% dump1090 dump1090 [.] > demodulate2400 > 0.09% 0.00% fvLogger [kernel.kallsyms] [k] > __ret_fast_syscall > 0.09% 0.00% dump1090 [unknown] [.] > 0x00041002 > 0.08% 0.01% fvUnisocket [kernel.kallsyms] [k] > usb_submit_urb > 0.08% 0.00% fvLogger fvLogger [.] > 0x000804c4 > 0.08% 0.00% fvHealth [kernel.kallsyms] [k] > __ret_fast_syscall > 0.08% 0.01% fvUnisocket [kernel.kallsyms] [k] > usb_hcd_submit_urb > 0.07% 0.00% swapper [kernel.kallsyms] [k] > arch_cpu_idle_exit > 0.07% 0.01% swapper [kernel.kallsyms] [k] > ledtrig_cpu > 0.07% 0.01% fvUnisocket [dwc2] [k] > _dwc2_hcd_urb_enqueue > 0.07% 0.00% swapper [kernel.kallsyms] [k] > led_trigger_event > 0.06% 0.06% swapper [kernel.kallsyms] [k] > _raw_read_unlock_irqrestore > > I've no idea what all that means. Any thoughts? > >> On Monday, October 31, 2022 at 11:32:21 AM UTC-5 Steven Sokol wrote: >> I tried sending SIGABRT, but the process did not respond - continued running >> in the runaway state. I can kill it with SIGKILL but that doesn't generate a >> core. Can you suggest a specific kill command that will? Thanks! >> >>> On Monday, October 31, 2022 at 10:03:27 AM UTC-5 ren...@ix.netcom.com wrote: >>> I would simply use kill to send a signal that generates a core dump and >>> exits. Make sure you have the shell and security settings setup to all this >>> to happen. >>> >>>>> On Oct 31, 2022, at 9:55 AM, Steven Sokol <st...@stevensokol.com> wrote: >>>>> >>>> I tried doing that and it did not seem to work: >>> >>>> >>>> root@pi4cm1(rw):/# gcore -o ~/lockup.core 22022 >>>> Unable to attach: program exited with code 1. >>>> You can't do that without a process to debug. >>>> The program is not being run. >>>> gcore: failed to create /root/lockup.core.22022 >>>> >>>> The attempt somehow killed the process. >>>> >>>>>> On Wednesday, October 26, 2022 at 10:03:30 AM UTC-5 Konstantin Khomoutov >>>>>> wrote: >>>>>> On Wed, Oct 26, 2022 at 08:45:00AM -0500, Robert Engels wrote: >>>>>> >>>>>> > Trigger a core dump then use gdb on the core file. >>>>>> >>>>>> Also, the gdb is usually shipped with the `gcore` helper which can >>>>>> attach to >>>>>> the specified PID and dump its core. >>>>>> >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "golang-nuts" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an >>>> email to golang-nuts...@googlegroups.com. >>> >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/golang-nuts/75272721-b821-4081-af23-2c84147bfadcn%40googlegroups.com. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/f8f513e4-643e-48f3-ac92-df1320ab65c4n%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CEE6C857-802F-43B3-95B8-C9DA2FBB1DEE%40ix.netcom.com.
