Also, enabling and generating core dumps is somewhat OS version specific - even between Linux versions - so you probably need to check your docs.
> On Nov 1, 2022, at 11:14 AM, Robert Engels <reng...@ix.netcom.com> wrote: > > > Are you certain you aren’t integrating with some C library that is > interfering with the default signal handling? > >>> On Nov 1, 2022, at 11:12 AM, Steven Sokol <st...@stevensokol.com> wrote: >>> >> Yep, I need to figure out how to generate a core dump. I've tried all the >> usual methods without success. Any suggestions for alternate methods would >> be greatly appreciated. >> >> When the process is killed (SIGKILL) the system does return to its normal >> load. (Under production conditions systemd immediately restarts it.) >> >>> On Tuesday, November 1, 2022 at 10:38:12 AM UTC-5 ren...@ix.netcom.com >>> wrote: >>> 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...@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/1942dcc8-0cf3-444b-a185-03a682dc9dacn%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/C6AFE016-347F-4E47-9056-75DB151DF660%40ix.netcom.com.
