Le 22/09/2021 à 10:45, Andrey Af via FreeRDP-devel a écrit :
I have a test server based on freerdp-2.4.git,
at some indefinite point in time, the working session freezes.
There are no errors. I received a dump via gdb:
#0 0x00007fb473062ccd in poll () from /lib64/libc.so.6
#1 0x00007fb474b510d0 in transport_bio_simple_ctrl () from
/lib64/libfreerdp2.so.2
#2 0x00007fb474b51804 in transport_bio_buffered_ctrl () from
/lib64/libfreerdp2.so.2
#3 0x00007fb474b0ff0a in bio_rdp_tls_ctrl () from /lib64/libfreerdp2.so.2
#4 0x00007fb474b5888c in transport_write () from /lib64/libfreerdp2.so.2
#5 0x00007fb474b56637 in fastpath_send_update_pdu () from
/lib64/libfreerdp2.so.2
#6 0x00007fb474b5ba73 in update_send_bitmap_update () from
/lib64/libfreerdp2.so.2
#7 0x000000000045f3b7 in
LTSM::Connector::RDP::clientUpdateBitmapPlanar (this=0x56e6c0,
peer=..., reg=..., reply=std::shared_ptr (count 1, weak 0) 0x62bc40)
Here I see that the fastpath_send_update_pdu call is waiting for something.
On the client side, I used xfreerdp-2.4.
Who can tell me where the error might be?
About my project, maybe someone will want to check it out (LinuxTerminalService)
https://github.com/AndreyBarmaley/linux-terminal-service-manager
Hi,
Hard to tell just based on your stacktrace. I've seen that in your
enterEventLoop() function no polling at all is done, perhaps it's
related and makes the write block. It's most probable that with SSL we
rely on the fact that a correct polling is done when calling
peer->CheckFileDescriptor() (I mean we shall not call it if no read
indicator has been noticed).
You can have a look at the ogon project
(https://github.com/ogon-project/ogon) that does much the same thing as
you also using FreeRDP for the transport.
Best regards.
--
David FORT
website: https://www.hardening-consulting.com/
_______________________________________________
FreeRDP-devel mailing list
FreeRDP-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel