bug#42740: Segfault in libssh during ‘guix copy’

["Ludovic Courtès" <ludo@gnu.org>]

Ludovic Courtès <ludo@gnu.org> 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’.