Signal handler conflict with Go applications using multiple libraries (SIGPIPE/SA_ONSTACK)

[caldempsey]

Hey @alexbrainman

I've been using your ODBC driver (which has been great, thank you!) alongside Apache Spark Connect in a Go application, and I ran into an interesting signal handling issue that I wanted to bring to your attention.

When both libraries are used in the same process, I occasionally get this panic:

signal 13 received but handler not on signal stack
mp.gsignal stack [0xc000804000 0xc00080c000], mp.g0 stack [0x7fff917fb280 0x7fff91ffae80], sp=0xc0004ade20
fatal error: non-Go code set up signal handler without SA_ONSTACK flag

After some debugging, I found this only happens when both the ODBC driver (specifically Simba Spark ODBC in my case) and Spark Connect are running together. I think the issue is the underlying ODBC driver installs a SIGPIPE handler without the SA_ONSTACK flag that Go's runtime requires. I've documented the investigation here: apache/spark-connect-go#152 (comment)

The workaround I'm using is to ignore SIGPIPE entirely:

func init() {
    signal.Ignore(syscall.SIGPIPE)
}

I think this works fine if both libraries handle EPIPE errors properly through return values.

Would you be able to give the PR a read? I wanted to run this by you as I consider you an expert in all things ODBC. I'm not sure if this is something you might consider trying to handle on your end, in case this represents an issue with the ODBC driver, or whether my approach make sense or if we can do better. Sweeping the issue under the rug seems drastic but also logical.

Of course, this might represent a problem with the underlying Spark Simba C ODBC drivers than your Go wrapper, but I'm really keen to learn about any insights from your experience maintaining this library, or whether this is something that should be handled here, I still consider myself a junior when it comes to truly rolling in the deep of the Kernal, but having a blast learning about it all.

Thanks for your time and for maintaining this project!

[alexbrainman]

Hello @caldempsey

When both libraries are used in the same process, I occasionally get this panic:

...

After some debugging, I found this only happens when both the ODBC driver (specifically Simba Spark ODBC in my case) and Spark Connect are running together. I think the issue is the underlying ODBC driver installs a SIGPIPE handler without the SA_ONSTACK flag that Go's runtime requires. I've documented the investigation here: apache/spark-connect-go#152 (comment)

The workaround I'm using is to ignore SIGPIPE entirely:

The workaround sounds reasonable to me, if the solution works for you.

The unixodbc and driver's code is written in C, and you have no control over it. And even if you could adjust the C code, I am not sure how you would control SIGPIPE handlers for different / incompatible bits of C code. Mind you, I am not a Linux expert.

Would you be able to give the PR a read?

I looked at your PR, and I don't see how I can help.

I wanted to run this by you as I consider you an expert in all things ODBC. I'm not sure if this is something you might consider trying to handle on your end, in case this represents an issue with the ODBC driver, or whether my approach make sense or if we can do better.

I don't see how we can add some code here in github.com/alexbrainman/odbc to help general user. This is something that every Cgo user encounters when they call some incompatible with each other C code from their Go code.

Sweeping the issue under the rug seems drastic but also logical.

If the solution works for you, just go with that until you find some problems.

Alex