All sounds probable reasonable.
https://wiki.archlinux.org/title/Core_dump
<https://wiki.archlinux.org/title/Core_dump> has additional options that may
help generate the core dump.
Still, if the process is stuck in the kernel, the only option should be a kill
signal. If the other signals can cause the process to exit, then it doesn’t
look like something is configured properly to allow the core to be generated.
The core file is generated by the kernel not libc linked to the application.
These are all of the signals that generate a core dump in the kernel when the
process exits:
#define SIG_KERNEL_COREDUMP_MASK (\
rt_sigmask(SIGQUIT) | rt_sigmask(SIGILL) | \
rt_sigmask(SIGTRAP) | rt_sigmask(SIGABRT) | \
rt_sigmask(SIGFPE) | rt_sigmask(SIGSEGV) | \
rt_sigmask(SIGBUS) | rt_sigmask(SIGSYS) | \
rt_sigmask(SIGXCPU) | rt_sigmask(SIGXFSZ) | \
SIGEMT_MASK )
so you might try killing with each of these and see if you can get a core dump.
> On Nov 7, 2022, at 11:09 AM, Steven Sokol <st...@stevensokol.com> wrote:
>
> FWIW - I opened a bug with the go core team and after some discussion one of
> them suggested I build the program specifying "GOARM=7". It appears to have
> resolved the issue - I've been running the full stack of programs on two
> different units (Pi 4 Model B, CM4) for the past week without any sign of the
> runaway. A friend with a great deal more low-level Linux experience has some
> thoughts on what might be happening:
>
> Here is my speculation. There is a latent locking issue somewhere in the
> runtime and the much slower workaround implementation that goes through kuser
> helper makes the problem more statistically likely because the probability of
> contention is higher. The native version will make the lock action much
> faster and reduce the probability but if you want to be a gracious go citizen
> get a stack dump. Likely if you change to v7 it may go away but you'll never
> be sure :)
>
> With regards to my total failure to create a core dump, he posits:
>
> The reason for sigabort and friends not working is that the user helper may
> be considered as a syscall or being in the kernel so it will abort as soon as
> it leaves that call but if it spins forever....
>
> So not a particularly satisfying outcome, but the problem is probably
> (possibly?) solved. Anyone have any thoughts on either the fix or my friend's
> theory?
> On Thursday, November 3, 2022 at 4:13:25 AM UTC-5 Konstantin Khomoutov wrote:
> On Mon, Oct 31, 2022 at 09:32:21AM -0700, 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!
>
> Sending SIGKILL is worthless because this signal is never delivered to the
> target process: it's actually a request to the kernel to forcibly bring the
> process down without any extra fuss.
>
> To make the process drop the core, you should first make sure that this is
> allowed for the process - usually by running
>
> ulimit -c unlimited
>
> in the shell which starts the process (well, exactly how to make sure this
> ulimit parameter is set for your process heavily depends on how it starts up)
> and then sending a process any of the signals with "drop the core" default
> disposition - see the signal(7) manual page - and not handled by the process
> itself using the os/signal package).
> On Linux, SIGQUIT is typically the signal you want.
> And on a terminal (including virtual terminals such as Linux's virtual
> consoles, XTerm, GNOME Terminal, screen, tmux etc) sending of this signal is
> bound to Ctrl-\ by default. So, if you can run this program in the foreground
> mode - that is, from a shell session attached to a terminal, you can do
>
> ulimit -c unlimited
> /path/to/the/process
> # idenfity lockup
> # press Ctrl-\ to have the process sent the SIGQUIT
>
>
> --
> 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
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/986a0501-084c-4d56-9afd-c1eb982b2cb9n%40googlegroups.com
>
> <https://groups.google.com/d/msgid/golang-nuts/986a0501-084c-4d56-9afd-c1eb982b2cb9n%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/5F4C9D63-975F-4E84-9BC3-C0EEB83A8DBA%40ix.netcom.com.
