SIGCHILD handling in Mac OS about qml

[quarnster]

FWIW using C.system instead of the go equivalent works as a work around

[niemeyer]

Please note that these calls are not coming from the qml package. The qml package is just calling back onto the test code at:

main.(*tt).Test(0x42a7080)
    /private/tmp/test.go:14 +0x19b fp=0x5ffc440

Everything above it is not logic from qml.

It also looks like a problem in the Go runtime. I'll report this upstream.

[niemeyer]

Reported at http://golang.org/issue/7227

[niemeyer]

Are you still able to reproduce this issue? If so, can you please run it with GOTRACEBACK=2 and report back on http://golang.org/issue/7227?

Thanks!

[xlab]

Accidentally stepped on that rake too. My setup is OS X 10.9.3, Qt 5.3.0, Go — tested with both 1.3beta1 and 1.3beta2. The minimal reproducible code is

package main

import (
    "log"
    "os/exec"
    "gopkg.in/qml.v0"
)

func main() {
    qml.Init(nil)
    out, _ := exec.Command("date").Output() // [1]
    log.Println(string(out))
    engine := qml.NewEngine() // [2]
    log.Println("Hello?")
    _ = engine
}

Program hangs if [1] is getting called after qml.Init(nil) and if any of the go-qml's machinery was used after, like [2]. When hanged, 50% of CPU is used. In this particular case the program reacts on SIGABRT, but in my project, if a complex combination of go routines and for-select is used, this exec call just hangs my program and even the ^C is ignored.So I just kill -9.

I've visited http://golang.org/issue/7227, but seems that there is no any solution yet. 😢

[quarnster]

There's a workaround via monkeypatching sigaction et. al. tough

[niemeyer]

@quarnster Are you using that in an app? Maybe we should just do something similar in the qml package itself, to fix the SIGCHILD situation in Mac OS. There's already some memory fiddling to enable testing (see testing.go), but I was not so unhappy about these given it was only for testing. That said, if there's no way to have SIGCHILD working at all otherwise, maybe we should also do that in general for these functions.

[quarnster]

I am using it in various apps that appear to be more stable with such a work around in place. However it isn't a catch all solution as applications can still try and override the signal handlers by using the syscall directly. It is nonetheless a viable workaround that I'm presuming would catch most issues.

Reminder per this and this comment, it's enough to simply reset the signal handler trampoline on OSX for the issue to appear even if the signal handler itself isn't touched. This impacts any signal that any lib might try and install even if it's then trying to be "good" and chain the handlers as the standard library doesn't expose the ability to set the trampoline resulting in it getting overwritten when not using the syscall directly.

While Linux allows signal handlers to be chained, the right flags must be used when installing the new handler, so it's still a potential issue on Linux.

The actual code used is in hack.go and utils.c. cinit is used because doing for example &C.signal returns an address to a CGO wrapper function rather than the actual libc function we want to patch.

I don't know of any issues caused by applying the monkey patching.