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.
