[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ludovic Courtès
Subject: bug#42740: Segfault in libssh during ‘guix copy’
Date: Sat, 29 Aug 2020 16:31:20 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

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


This workaround is similar to that of 2017:


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.)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]