Conflict with golang programs

[sklimakov]

Hello.

I have a program in golang, which runtime sets a custom signal stack and signal handlers.
At startup the runtime calls a sigaction for almost every signal up to 64.
When I try to preload the libonload, it catches the syscall and prints the below error:

oo:test[160582]: ERROR: a signal handler for signal 54 can't be overwritten without breaking Onload.  Returning EINVAL error.
oo:test[160582]: You can change SIGONLOAD value in the Onload source code

Looks like nothing critical, and the calling program just have to deal with EINVAL.
However, it seems that onload does not initialize completely afterwards.

We cannot change the SIGONLOAD value to not interfere with this runtime behavior.
Likely, it is not a true reason why it does not work.

Do you have an idea how to work this around or what may stop onload from initialization?
Unfortunately, I do not have enough experience with unix signals and onload to solve it on my own.

A simple tcp client program to reproduce this behavior can be built with any linux/amd64 golang compiler .

package main

import (
    "os"
    "fmt"
    "net"
    "time"
)

func main() {
    if len(os.Args) < 2 {
        fmt.Println("usage:", os.Args[0], "ip:port")
        return
    }
    addr := os.Args[1]

    conn, err := net.Dial("tcp", addr)
    if err != nil {
        fmt.Println("err:", err)
        return
    }
    defer conn.Close()

    fmt.Println("connected to:", addr)

    for {
        _, err := conn.Write([]byte(time.Now().Format(time.UnixDate)))
        if err != nil {
            fmt.Println("err:", err)
            return
        }
        time.Sleep(1 * time.Second)
    }
}

Onload version is 8.1.2.26

Thank you for any advice!

[ivatet-amd]

Hi @sklimakov, and thank you for the repro!

Currently, Onload does not accelerate Golang applications because they do not use libc to make system calls and, therefore, cannot be intercepted as-is with Onload. The Golang threading model might not be compatible with Onload as well. (@matthewr-xilinx raised internally at ON-11621 CC @abower-amd.)

I think you are correct about SIGONLOAD. The Golang runtime tries to install signal handles at initsig() and seems to cope well with not being able to do so for some signals. (It might be similar to what @krishd-amd has observed at ON-14337.)

Keeping the issue open for the colleagues to correct the above statements if they are not right or inaccurate.