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
>>
>> <https://groups.google.com/d/msgid/golang-nuts/75272721-b821-4081-af23-2c84147bfadcn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
--
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.
