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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/986a0501-084c-4d56-9afd-c1eb982b2cb9n%40googlegroups.com.

Reply via email to