Ludovic Courtès <[email protected]> skribis: > So we have the finalization thread closing a channel of session > 0x12a4b20 (which causes a write on the channel), and the main thread > writing to a channel of that same session. This is exactly what I > described at <https://issues.guix.gnu.org/26976#11>: > > AIUI, that means there’s one output compression buffer per session, > and it’s not thread-safe (in Guile 2.2 finalizers are called from a > separate thread.) > > I think the fix, in Guile-SSH, is to associate each libssh object > (session, channel, etc.) with a mutex, and to protect all uses of the > libssh object by that mutex. > > Artyom, WDYT? Do you think you could take a look into that? > > In the meantime, I’ll look for the origin of the channel port that’s not > explicitly closed and see if we can work around it.
I’ve pushed this change on our side to explicitly close channels and sessions: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=61fe9ced7da7eefceb931af0cb7363b721f5bdd6 This workaround is similar to that of 2017: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=8e469b67f95cfe5b95405b503b8ee315fdf8ce66 It’s really just a workaround so I think we should fix the core issue in Guile-SSH (or libssh) so it doesn’t pop up again next month—it’s hard to ensure code that opens a channel explicitly closes it. Anyway, I would welcome tests using ‘guix copy’, ‘guix deploy’, and offloading. (For offloading, make sure to run the daemon from your build tree.) Ludo’.
