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

Reply via email to