IRC channel logs

<sneek>dsmith: wb

<old>in guile 3.0.1, I get a abort() signal from scm_fork(), both in child and parent within pthread_once()

<old>s/3.0.1/3.0.10/g does that sound familiar to some?

<old>seems like start_signal_delivery_thread

<old>is aborting

<old>219 if (signal_delivery_thread_state != STOPPED)

<old>220 abort ();

<old>that's very odd. somehow, the state of the signal delivery thread is not stopped for both the parent and the child

<flurando>couldn't help, still on 3.0.9 ><

<flurando>old: Is there any example (code, scripts, whatever) to run? I would like to try on my machine.

<old>unfortunatelly, I can only reproduce in a VM on sourcehut on a debian build of Guile for very specific test of a test suite ..

<old>I have to run it multiple time to get the error to pop

<old>sounds very much like race condition

<old>I will try to make a small reproducer

<flurando>old: well, seems quite hard-core to me, edge test or so... Then I have nothing to help except executing your reproducer in the future

<flurando>small VM or docker image is also OK, if they are not so bloated and could be run with qemu / podman

<old>I will try to find minimal producer thanks!

<old>hmm the code in scmsigs.c can be buggy

<old>I think there is a possible that the take_signal() handler writes to a file-descriptor that was closed

<old>which should return EINVAL, but it's also possible that another thread open a new file and the fd is reeused

<old>well should not be the case from what I can read

<apteryx>is there a trick in Guile I could use to lazily load a module only if it's defined? I tried autoload, but it failed because the module does not exist in a context where the module is being byte compiled.

<flurando>apteryx: only try catch, I suppose

<mwette>apteryx: I guess you may have success with Module System Reflection. See the manual: resolve-module, module-interfaces, etc.

<old>apteryx: resolve-interface ?

IRC channel logs

2025-11-01.log