Signal 13 received but handler not on signal stack

[JasonMurphy13]

Randomly, my K8S pods are panicking with Signal 13 received but handler not on signal stack error followed by a dump. I am assuming that my app is losing network connectivity intermittently, but should be recovering quickly. Instead my pod is crashing and restarting.

mq-golang version: v5.6.7
mq C version: v9.4.4.0

I have tried setting the environment variable MQS_NO_SYNC_SIGNAL_HANDLING=true as well as changed my go code to capture signal 13 itself, but the error is still present. Is there any solution to this with my own code, or do i need to open a bug with the C IBM code

[ibmmqmet]

Signal 13 is SIGPIPE. That's not considered a synchronous signal, so the MQS_NO_SYNC_SIGNAL_HANDLING wouldn't be expected to have any effect. I tried a few experiments and couldn't get your error.

But I did see a difference between a local connection (a Go signal handler in my app did get called) compared to a client connection (the Go signal handler was not called). Which tells me that the MQ client library is probably doing something with the signal - not surprising as it's doing network stuff. My suspicion would be that it's not dealing with the signal in the way that Go would like with the SA_ONSTACK option but that's not something I can deal with here. It would have to be handled through normal support channels - though I don't know what their reaction would be, or whether they'd consider it a bug. Or what broader effects it might have if the C code were changed.

[JasonMurphy13]

I opened a ticket with IBM and they sent me the following:

This is a go lang library problem. IBM is not responsible for third party libraries, please, reach out to the go lang team for resolution.

I do not know what to do here. I cannot see the C code to do my own research, and the IBM team is either not willing or unable to help.

[ibmmqmet]

Talking to the main L3 person, he says to try again with support - push back on them and explain this is likely an issue with the C client code. If we get the ticket number, then we may be able to also add to it from this end.

[JasonMurphy13]

Ticket number is TS021392277

[ravellan]

I am also interested in the resolution of this. Been seeing it from time to time on openshift deployments and also drew the conclusion that the C client and the golang runtime is not best friends. Never pursued it through the official channels though so thanks for placing the ticket.

[JasonMurphy13]

I have tested a patch from IBM to their C code and the issue appears to have gone away. I am waiting for their official release with the fix and will give updates here.