MSTSC crashes when resolution is changed by maximizing on a different monitor #1928
Comments
|
These errors from xrdp mean the other client has gone away unexpectedly:- So something is happening which is upsetting I've got a twin-screen Windows 10 VM set up as you have above, and I'm unable to reproduce your crash. Windows version here is 21H1 (OS build 19043.1052), and I'm using a development build of xrdp. What platforms are you using? Are you using a .ini file to start the connection? |
|
my windows version 21H1 19043.1023.
are your twin-screen have different resolution? I will try other rdp client later |
|
Yes - that's what I've got. My dialog looks like yours, but in English rather than Chinese. Since it's a VM I've set my screen resolutions to match yours. A couple of other questions for you:-
|
xrdp version 0.9.15
I try another windows machine (21H1 19043.1055) mstsc.exe. and there was no internal error.
it is a client-side bug. I will try to upgrade this machine and try again. |
crash remained after upgrading system version. I compare two machine's mstsc, and found that options determine crashing or not. |
|
Can you also confirm with 16bpp color * "LAN", "Auto detect"? |
16bpp is ok for |
|
I've reproduced this by using a LAN setting and 24bpp colour. The debug logs are required to get some idea of what's going on. Here's what I've got so far from xrdp:- xrdp.log[20211119-11:57:10] [DEBUG] [dynamic_monitor_data(xrdp_mm.c:1080)] dynamic_monitor_data: msg_type 2 msg_length 56 [20211119-11:57:10] [DEBUG] [dynamic_monitor_data(xrdp_mm.c:1092)] MonitorLayoutSize 40 NumMonitor 1 [20211119-11:57:10] [DEBUG] [dynamic_monitor_data(xrdp_mm.c:1107)] Flags 0x00000001 Left 0 Top 0 Width 1920 Height 1200 PhysicalWidth 637 PhysicalHeight 421 Orientation 0 DesktopScaleFactor 100 DeviceScaleFactor 100 [20211119-11:57:10] [DEBUG] [libxrdp_send_pointer(libxrdp.c:719)] sending cursor [20211119-11:57:10] [DEBUG] [libxrdp_send_pointer(libxrdp.c:747)] libxrdp_send_pointer: fastpath [20211119-11:57:10] [DEBUG] [xrdp_rdp_send_fastpath(xrdp_rdp.c:785)] xrdp_rdp_send_fastpath: no_comp_len 3221, fragmentation 0 [20211119-11:57:10] [DEBUG] [xrdp_sec_send_fastpath(xrdp_sec.c:1921)] xrdp_sec_send_fastpath: no crypt [20211119-11:57:10] [DEBUG] [libxrdp_send_pointer(libxrdp.c:719)] sending cursor [20211119-11:57:10] [DEBUG] [libxrdp_send_pointer(libxrdp.c:747)] libxrdp_send_pointer: fastpath [20211119-11:57:10] [DEBUG] [xrdp_rdp_send_fastpath(xrdp_rdp.c:785)] xrdp_rdp_send_fastpath: no_comp_len 3221, fragmentation 0 [20211119-11:57:10] [DEBUG] [xrdp_sec_send_fastpath(xrdp_sec.c:1921)] xrdp_sec_send_fastpath: no crypt [20211119-11:57:10] [DEBUG] [xrdp_painter_create(xrdp_painter.c:140)] xrdp_painter_create: [20211119-11:57:10] [DEBUG] [xrdp_painter_begin_update(xrdp_painter.c:243)] xrdp_painter_begin_update: [20211119-11:57:10] [DEBUG] [xrdp_orders_init(xrdp_orders.c:110)] xrdp_orders_init: fastpath [20211119-11:57:10] [DEBUG] [wm_painter_set_target(xrdp_painter.c:193)] wm_painter_set_target: [20211119-11:57:10] [DEBUG] [xrdp_painter_end_update(xrdp_painter.c:265)] xrdp_painter_end_update: [20211119-11:57:10] [DEBUG] [xrdp_painter_delete(xrdp_painter.c:171)] xrdp_painter_delete: [20211119-11:57:10] [DEBUG] [send_server_monitor_resize(xup.c:1307)] send_server_monitor_resize: sent resize message with following properties to xorgxrdp backend width=1920, height=1200, bpp=24, return value=0 [20211119-11:57:10] [DEBUG] [send_server_monitor_full_invalidate(xup.c:1334)] send_server_monitor_full_invalidate: sent invalidate message with following properties to xorgxrdp backend width=1920, height=1200, return value=0 [20211119-11:57:10] [DEBUG] [xrdp_rdp_recv(xrdp_rdp.c:519)] xrdp_rdp_recv: out code 0 (skip data) data processed by channel id 1007 [20211119-11:57:10] [DEBUG] [lib_mod_process_orders(xup.c:1386)] lib_mod_process_orders: type 1 [20211119-11:57:11] [DEBUG] [xrdp_painter_create(xrdp_painter.c:140)] xrdp_painter_create: [20211119-11:57:11] [DEBUG] [xrdp_painter_begin_update(xrdp_painter.c:243)] xrdp_painter_begin_update: [20211119-11:57:11] [DEBUG] [xrdp_orders_init(xrdp_orders.c:110)] xrdp_orders_init: fastpath [20211119-11:57:11] [DEBUG] [wm_painter_set_target(xrdp_painter.c:193)] wm_painter_set_target: [20211119-11:57:11] [DEBUG] [lib_mod_process_orders(xup.c:1386)] lib_mod_process_orders: type 61 [20211119-11:57:11] [DEBUG] [server_paint_rects(xrdp_mm.c:3192)] server_paint_rects: 0x55ae03f16af0 [20211119-11:57:11] [DEBUG] [lib_mod_process_orders(xup.c:1386)] lib_mod_process_orders: type 2 [20211119-11:57:11] [DEBUG] [xrdp_painter_end_update(xrdp_painter.c:265)] xrdp_painter_end_update: [20211119-11:57:11] [DEBUG] [process_enc_rfx(xrdp_encoder.c:329)] process_enc_rfx: [20211119-11:57:11] [DEBUG] [process_enc_rfx(xrdp_encoder.c:330)] process_enc_rfx: num_crects 3 num_drects 1 [20211119-11:57:11] [DEBUG] [xrdp_painter_delete(xrdp_painter.c:171)] xrdp_painter_delete: [20211119-11:57:11] [DEBUG] [process_enc_rfx(xrdp_encoder.c:393)] process_enc_rfx: rfxcodec_encode rv 0 [20211119-11:57:11] [DEBUG] [dynamic_monitor_data(xrdp_mm.c:1080)] dynamic_monitor_data: msg_type 2 msg_length 56 [20211119-11:57:11] [DEBUG] [dynamic_monitor_data(xrdp_mm.c:1092)] MonitorLayoutSize 40 NumMonitor 1 [20211119-11:57:11] [DEBUG] [dynamic_monitor_data(xrdp_mm.c:1107)] Flags 0x00000001 Left 0 Top 0 Width 1920 Height 1200 PhysicalWidth 637 PhysicalHeight 421 Orientation 0 DesktopScaleFactor 100 DeviceScaleFactor 100 [20211119-11:57:11] [DEBUG] [libxrdp_send_pointer(libxrdp.c:719)] sending cursor [20211119-11:57:11] [DEBUG] [libxrdp_send_pointer(libxrdp.c:747)] libxrdp_send_pointer: fastpath [20211119-11:57:11] [DEBUG] [xrdp_rdp_send_fastpath(xrdp_rdp.c:785)] xrdp_rdp_send_fastpath: no_comp_len 3221, fragmentation 0 [20211119-11:57:11] [DEBUG] [xrdp_sec_send_fastpath(xrdp_sec.c:1921)] xrdp_sec_send_fastpath: no crypt [20211119-11:57:11] [DEBUG] [libxrdp_send_pointer(libxrdp.c:719)] sending cursor [20211119-11:57:11] [DEBUG] [libxrdp_send_pointer(libxrdp.c:747)] libxrdp_send_pointer: fastpath [20211119-11:57:11] [DEBUG] [xrdp_rdp_send_fastpath(xrdp_rdp.c:785)] xrdp_rdp_send_fastpath: no_comp_len 3221, fragmentation 0 [20211119-11:57:11] [DEBUG] [xrdp_sec_send_fastpath(xrdp_sec.c:1921)] xrdp_sec_send_fastpath: no crypt [20211119-11:57:11] [DEBUG] [xrdp_painter_create(xrdp_painter.c:140)] xrdp_painter_create: [20211119-11:57:11] [DEBUG] [xrdp_painter_begin_update(xrdp_painter.c:243)] xrdp_painter_begin_update: [20211119-11:57:11] [DEBUG] [xrdp_orders_init(xrdp_orders.c:110)] xrdp_orders_init: fastpath [20211119-11:57:11] [DEBUG] [wm_painter_set_target(xrdp_painter.c:193)] wm_painter_set_target: [20211119-11:57:12] [DEBUG] [xrdp_painter_end_update(xrdp_painter.c:265)] xrdp_painter_end_update: [20211119-11:57:12] [DEBUG] [xrdp_painter_delete(xrdp_painter.c:171)] xrdp_painter_delete: [20211119-11:57:12] [DEBUG] [send_server_monitor_resize(xup.c:1307)] send_server_monitor_resize: sent resize message with following properties to xorgxrdp backend width=1920, height=1200, bpp=24, return value=0 [20211119-11:57:12] [DEBUG] [send_server_monitor_full_invalidate(xup.c:1334)] send_server_monitor_full_invalidate: sent invalidate message with following properties to xorgxrdp backend width=1920, height=1200, return value=0 [20211119-11:57:12] [DEBUG] [xrdp_rdp_recv(xrdp_rdp.c:519)] xrdp_rdp_recv: out code 0 (skip data) data processed by channel id 1007 [20211119-11:57:12] [DEBUG] [xrdp_mm_process_enc_done(xrdp_mm.c:2815)] xrdp_mm_process_enc_done: message back bytes 2914 [20211119-11:57:12] [DEBUG] [libxrdp_fastpath_send_frame_marker(libxrdp.c:1723)] libxrdp_fastpath_send_frame_marker: [20211119-11:57:12] [DEBUG] [xrdp_rdp_send_fastpath(xrdp_rdp.c:785)] xrdp_rdp_send_fastpath: no_comp_len 12, fragmentation 0 [20211119-11:57:12] [DEBUG] [xrdp_sec_send_fastpath(xrdp_sec.c:1921)] xrdp_sec_send_fastpath: no crypt [20211119-11:57:12] [DEBUG] [libxrdp_fastpath_send_surface(libxrdp.c:1641)] libxrdp_fastpath_send_surface: [20211119-11:57:12] [DEBUG] [xrdp_rdp_send_fastpath(xrdp_rdp.c:785)] xrdp_rdp_send_fastpath: no_comp_len 2940, fragmentation 0 [20211119-11:57:12] [DEBUG] [compress_rdp_5(xrdp_mppc_enc.c:972)] Compression algorithim produced a compressed buffer which is larger than the uncompressed buffer. compression ratio 0.979646, flags 0x1 [20211119-11:57:12] [DEBUG] [xrdp_rdp_send_fastpath(xrdp_rdp.c:810)] compress_rdp failed, sending uncompressed data. type 2, flags 1 [20211119-11:57:12] [DEBUG] [xrdp_sec_send_fastpath(xrdp_sec.c:1921)] xrdp_sec_send_fastpath: no crypt [20211119-11:57:12] [DEBUG] [libxrdp_fastpath_send_frame_marker(libxrdp.c:1723)] libxrdp_fastpath_send_frame_marker: [20211119-11:57:12] [DEBUG] [xrdp_rdp_send_fastpath(xrdp_rdp.c:785)] xrdp_rdp_send_fastpath: no_comp_len 12, fragmentation 0 [20211119-11:57:12] [DEBUG] [xrdp_sec_send_fastpath(xrdp_sec.c:1921)] xrdp_sec_send_fastpath: no crypt [20211119-11:57:12] [ERROR] [ssl_tls_log_error(ssl_calls.c:655)] SSL_write: I/O error [20211119-11:57:12] [ERROR] [xrdp_sec_send_fastpath(xrdp_sec.c:1936)] xrdp_sec_send_fastpath: xrdp_fastpath_send failed [20211119-11:57:12] [ERROR] [xrdp_rdp_send_fastpath(xrdp_rdp.c:834)] xrdp_rdp_send_fastpath: xrdp_sec_send_fastpath failed [20211119-11:57:13] [ERROR] [libxrdp_fastpath_send_frame_marker(libxrdp.c:1749)] libxrdp_fastpath_send_frame_marker: xrdp_rdp_send_fastpath failed [20211119-11:57:13] [DEBUG] [xrdp_mm_process_enc_done(xrdp_mm.c:2838)] xrdp_mm_process_enc_done: last set [20211119-11:57:13] [DEBUG] [xrdp_mm_update_module_frame_ack(xrdp_mm.c:2785)] xrdp_mm_update_module_ack: frame_id_server 10 [20211119-11:57:13] [DEBUG] [lib_mod_process_orders(xup.c:1386)] lib_mod_process_orders: type 1 [20211119-11:57:13] [DEBUG] [xrdp_painter_create(xrdp_painter.c:140)] xrdp_painter_create: [20211119-11:57:13] [DEBUG] [xrdp_painter_begin_update(xrdp_painter.c:243)] xrdp_painter_begin_update: [20211119-11:57:13] [DEBUG] [xrdp_orders_init(xrdp_orders.c:110)] xrdp_orders_init: fastpath [20211119-11:57:13] [DEBUG] [wm_painter_set_target(xrdp_painter.c:193)] wm_painter_set_target: [20211119-11:57:13] [DEBUG] [lib_mod_process_orders(xup.c:1386)] lib_mod_process_orders: type 51 [20211119-11:57:13] [DEBUG] [libxrdp_send_pointer(libxrdp.c:719)] sending cursor [20211119-11:57:13] [DEBUG] [libxrdp_send_pointer(libxrdp.c:747)] libxrdp_send_pointer: fastpath [20211119-11:57:13] [DEBUG] [xrdp_rdp_send_fastpath(xrdp_rdp.c:785)] xrdp_rdp_send_fastpath: no_comp_len 4245, fragmentation 0 [20211119-11:57:13] [DEBUG] [xrdp_sec_send_fastpath(xrdp_sec.c:1921)] xrdp_sec_send_fastpath: no crypt [20211119-11:57:13] [ERROR] [xrdp_sec_send_fastpath(xrdp_sec.c:1936)] xrdp_sec_send_fastpath: xrdp_fastpath_send failed All I can say at the moment is something seems to be going wrong in |
|
The code that is in XRDP currently for resize is a shadow of what I have now after working with Jay to get that enabled for the GFX branch. There are some fixes I have where I've refactored resizing into a state machine and also been much more aggressive about making sure that duplicate resizes don't happen, and blocked the bug that I describe below. It looks like this is somewhat related to a bug where, on initial connection, an X * Y resize is also sent over the dynamic display channel even though it's not necessary. In the past XRDP has had many issues with a resize-to-a-resolution-you're-already-at message. @matt335672 I'm happy to help debug this if you can elucidate some clear steps to reproduce. We could also jump on a Zoom call and look at it together. |
|
Thanks @Nexarian - that's a great offer. The crash doesn't happen when 'auto' is selected on the mstsc experience tab, so I need to work out exactly which option(s) is/are causing this to happen. I picked up on this late yesterday, so didn't have time for a lot of analysis. Also, when DEBUG logging is selected in development mode, things slow to a crawl. After the weekend I'll do some analysis and post the info here. At the least I'm sure you'll want to check the GFX branch isn't affected. |
|
No real progress on this this week. I've managed to cause a couple of crashes with xfreerdp but they don't seem to be related to this one! The only way I can reproduce it currently is with a twin monitor setup on Windows. Monitors are different sizes. Procedure is as follows:-
I'll carry on trying to reproduce it with remmina or xfreerdp next week. |
|
I've found one reason why this is happening. When the screen resizes, the xorgxrdp driver enters [ 11703.161] rdpClientConProcessMsgClientInput: invalidate x 0 y 0 cx 1920 cy 1200 [ 11703.161] rdpClientConProcessMsgVersion: version 0 0 0 1 [ 11703.161] rdpClientConProcessScreenSizeMsg: set width 1920 height 1200 bpp 24 [ 11703.162] rdpClientConProcessScreenSizeMsg: shmemid 98335 shmemptr 0x7fdd99533000 [ 11703.162] rdpRRScreenSetSize: width 1920 height 1200 mmWidth 508 mmHeight 318 [ 11703.162] rdpRRGetInfo: [ 11703.162] screen resized to 1920x1200 [ 11703.162] rdpClientConProcessScreenSizeMsg: RRScreenSizeSet ok=[1] [ 11703.164] rdpClientConProcessMsgClientInput: invalidate x 0 y 0 cx 1920 cy 1200 [ 11703.164] rdpClientConProcessMsgClientInfo: [ 11703.164] got client info bytes 7072 [ 11703.164] jpeg support 0 [ 11703.164] offscreen support 1 [ 11703.164] offscreen size 7864320 [ 11703.164] offscreen entries 100 [ 11703.164] client can not do offscreen to offscreen blits [ 11703.164] client can do new(color) cursor [ 11703.164] client can not do multimon [ 11703.164] rdpRRSetRdpOutputs: numCrtcs 1 numOutputs 1 monitorCount 0 [ 11703.164] rdpRRSetRdpOutputs: update output 0 left 0 top 0 width 1920 height 1200 [ 11703.164] rdpRRUpdateOutput: [ 11703.165] rdpLoadLayout: keylayout 0x00000809 variant display 12 [ 11703.165] rdpkeybChangeKeyboardControl: [ 11703.165] rdpkeybChangeKeyboardControl: autoRepeat on [ 11703.166] rdpkeybChangeKeyboardControl: [ 11703.166] rdpkeybChangeKeyboardControl: autoRepeat on [ 11703.174] rdpClientConProcessMsgClientInput: invalidate x 0 y 0 cx 1920 cy 1200 [ 11703.175] rdpClientConProcessMsgVersion: version 0 0 0 1 [ 11703.175] rdpClientConProcessScreenSizeMsg: set width 1920 height 1200 bpp 24 [ 11703.176] rdpClientConProcessScreenSizeMsg: shmemid 98336 shmemptr 0x7fdd99533000 [ 11703.176] rdpClientConProcessMsgClientInput: invalidate x 0 y 0 cx 1920 cy 1200 [ 11703.177] rdpClientConRecv: g_sck_recv failed(returned -1) In this example the shared memory ID changes to 98335, and then to 98336. The xup routine Fix is probably not to re-allocate the memory region if it will be exactly the same size. I'll add a PR for this tomorrow to xorgxrdp for review. |
|
After retesting with neutrinolabs/xorgxrdp#203, I've found that there are other causes for this problem. neutrinolabs/xorgxrdp#203 seems to fix the problem provided I build without RFX enabled. Once RFX is enabled, the client exits on resize after sending a TS_CONFIRM_ACTIVE_PDU. I'll carry on digging. |
|
@matt335672 I think the cause may be an issue that plagues the resize code in general. When resizing is enabled, in addition to the initial screen connection most clients send a second resize message on the DISPLAY channel to resize to the same value. In the prototype I have where this works with EGFX, I solved this by refactoring the resizing code so that when a display resize comes in it's not processed immediately, but instead is added to a queue that is then processed as a state machine using wait objects. The queue is pre-populated with a NULL value that automatically rejects the first message on startup. This might also be the fix we need to proceed with here. Thoughts? |
|
This is not quite the same - I'm getting two identical DISPLAYCONTROL_MONITOR_LAYOUT_PDUs for the same size on the DISPLAY channel in quick succession when I go full-size on a single screen (and not before). I set a breakpoint on If your state machine handles that, we can look at a PR to get the SM in now. It might make merging your code later a little easier. Are you able to reproduce this fault? With neutrinolabs/xorgxrdp#203, everything seems solid with mstsc.exe and moving single screens about until I enable RFX. At that point, following the resize, we're sending the client something it doesn't like, and the client exits. So that's something that needs to be located anyway. While we're in that area, am I correct in thinking that xorgxrdp and the xup module always used shared memory? I need to know that to fully address neutrinolabs/xorgxrdp#199. I'm pretty sure it's the case, but I'd value a confirmation from someone who understands this a bit better. |
|
Ah, I never actually fully tested the resize code with MSTSC as its feature set was woefully incomplete, but I agree we need to test it. Do I NEED two non-identical monitors? If I do, that's slightly annoying. Maybe I can just change the resolution of one of them. As to xup and xorgxrdp, the only caveat in what you said is "ALWAYS" with shared memory. I'm not sure it's always, but I've never seen an exception to it. I would say let's assume that to be true unless we find evidence otherwise. My state machine code would solve the case of multiple resize messages that are all the same, as well, because the first condition of rejection of an item on the queue is if it's trying to resize to the same thing that already exists. It will add it to the queue, process the first resize, then delete the second. In any case the state machine code is broken up over several bits. We'll need to adapt it for non-GFX use cases for now. I'll post a description of how it works in the Gitter. I want us to make sure we're all on board with this architecture in case changes need to be made. Here are the most significant parts in my view. https://github.com/Nexarian/xrdp/blob/resize_egfx_nvenc_helper_features/xrdp/xrdp_mm.c#L1441 |
|
I appreciate this is complicated. If we can merge incoming stuff to fix this issue, it should make our lives easier moving forward, so I'm up for that. This is the only situation I've seen where mstsc.exe sends a resize request. If you're going to test your state machine with this, the two use-cases are "monitors are different resolutions", and "monitors are the same resolution". So if you've got two the same and you can set the resolution on one down a bit, that will cover both use-cases. Sounds ideal. I've got a twin-monitor VM which I use to test this stuff. That's another way to do it, but it's fiddly to set up, By all means post a description on Gitter, but I think the final place for designs should probably be the Wiki, as it gets really hard to find stuff on Gitter after some time has elapsed. I appreciate that this is likely to be complex. As well as the resolution changing, we probably need to support a use-case where the resolution stays the same but the monitor size changes (i.e. the user moves the screen from a 25-inch 1920x1080 monitor to a 27-inch 1920x1080 monitor. At least the xrandr protocol allows that to happen. That may be awkward to test. The reason I'm keen on knowing whether we always use shared memory is to be able to put neutrinolabs/xorgxrdp#199 to bed. Also, if we always use shared memory, the use-case of running xrdp on one machine and sesman on another goes away, which makes a move to UNIX domain sockets for IPC a bit easier - we know virtually no-one will be using the split-machine use-case. @jsorg71 - can you advise as as to whether we can safely assume that the xup/xorgxrdp interface always uses shared memory? |
|
I just tested this with single-monitor:
This works, now to test more complex use-cases... |
|
Ok, this seems to ONLY reproduce on systems that have more than one monitor for the client. I think, unfortunately, this is a gap in my original code. I was sorta hand-wavy about the way I handled the multi-mon situation because in general if we're resizing, the assumption is we revert to only one monitor. As you know some of my other PRs that are in the works are meant to deal with this issue explicitly, so I think I need to work on cleaning up this entire space. Both improved handling of the DISPLAY_CONTROL PDU (unified with the legacy messages for multi-mon) as well as the queue approach should help this. |
|
Glad you found it - that's the only way I could reproduce it too. The duplicate PDUs are definitely causing a problem, but I also saw a couple of crashes that were not related to that. |
|
@matt335672 Ok, I have made progress on this! First, with #2175 and neutrinolabs/xorgxrdp#203 combined, MSTSC DOES NOT crash when a performance setting less than "LAN" is used (WAN "10 Mbps or higher with high latency" or lower, that is). Set it to LAN and it does crash. From my reading of /var/log/xrdp.log, in both cases the RemoteFX codec is being used. Thus, I'm not clear on exactly what the difference is in the protocol or what it is that MSTSC is expecting at higher network bandwidths. I followed these instructions on how to enable error logs from MSTSC in Windows: https://support.oneidentity.com/one-identity-safeguard-for-privileged-sessions/kb/331680/gathering-rdp-event-logs-from-windows-10-machines Maybe one of you can see something obvious? This is baffling as this resizing code works with FreeRDP, the App Store client, and the Mac OS version of RDP. Unfortunately, MSTSC is the reference implementation, so we need to fix this :/ |
|
I think this is our answer: #843 I think I know the problem now. Note that here: https://github.com/neutrinolabs/xrdp/blob/devel/xrdp/xrdp_encoder.c#L92, we create the encoder. And guess what? The encoder's creation is dependent on the size of the session. That means, when we resize, we have to delete and re-create the encoder (https://github.com/neutrinolabs/xrdp/blob/devel/xrdp/xrdp_encoder.c#L142). However, that is only called here right now: https://github.com/neutrinolabs/xrdp/blob/devel/xrdp/xrdp_mm.c#L158 Fortunately, #2175 is the first step to the answer. Add in another state machine step that deletes and then recreates the encoder, and we're good! I already did this for GFX use cases, but I forgot that it also applies to RFX as well! I'm out of time to work on this tonight, but I'd love your thoughts on if this is the right approach and/or how to change it. |
|
I did wonder about the threading maybe being a problem here. If I understand it right (and please tell me if I've got this wrong), the encoder is busy processing the shared memory area when the resize comes in. If that's the case, you seem to have a couple of options:-
|
|
Look at the code for So really all I had to do to fix the LAN resizing crash with MSTSC was to put a delete encoder at the beginning of the resize operation, and a re-create after the resize had finished (right before the invalidate signal is send to xorgxrdp). Try out #2175 and let me know if you can reproduce the MSTSC crash (with or without RFX). I can't anymore! I believe it's fixed :) The PR still has a few things that need to be cleaned up, but it's good enough for you to start reviewing it. |
|
@matt335672 More targeted PR that fixes only this issue: #2291 |
|
Merged in the fix. I believe this can be resolved. @okhowang can you confirm? |
|
I use win11 now, test with latest devel |
|
@okhowang What were the exact steps you used to reproduce this crash? |
|
|
You pasted xorgxrdp log so did you mean xorgxrdp craches? The fix @Nexarian provided is for xrdp crash. |
no, I dont' known which component went wrong. here is xrdp.log and xrdp-sesman.log |
Nexarian
changed the title
|
|
|
Another tidbit from the logs is the scale factor. The 4K display is scaled. If you set the 4K display to a scale factor of 100% instead of the default 200% does this still happen? If not, then we need to work on incorporating this fix: #1692 |
|
I use two 4K monitor with 200% scale. |
|
Then I have enough to reproduce this. Give me a few days to test this. I have to dig out my old 1080p monitor :) |
|
Was able to reproduce this. You don't actually need a 4K monitor and an HD monitor. You just need to have 2x monitors next to each other. Here's my setup, note that both of these monitors are actually 2560x1440 native, you just change the resolution of one of them to both a different resolution AND a different scale. If you just change the scale but not the resolution, nothing changes. Monitor 1: 2560x1440 @ 100% Connect with MSTSC maximized on Monitor 1. Restore, move to Monitor 2, then Maximize. Result: MSTSC connection drops, but no error message is broadcasted. |
|
I suspect in order to fully fix this we have to finish: neutrinolabs/xorgxrdp#172 However, there may be a way to at least make sure the session doesn't crash... |
While this feature is part of other branches for testing EGFX integration, it somehow never made it into devel. This should fix neutrinolabs#1928, for real this time!
While this feature is part of other branches for testing EGFX integration, it somehow never made it into devel. This should fix neutrinolabs#1928, for real this time!
|
@okhowang Actually we don't need neutrinolabs/xorgxrdp#172 to fix this. Turns out the reason this is happening is due to a bug I fixed long ago in my https://github.com/Nexarian/xrdp/tree/mainline_merge branch, and for some reason it didn't make it over! |
|
@metalefty @matt335672 @okhowang Please test and let me know if #2300 fixes this for you. |
While this feature is part of other branches for testing EGFX integration, it somehow never made it into devel. This should fix neutrinolabs#1928, for real this time!
Nexarian/block_resize_if_already_resized works for me |
|
Excellent, I'll wait for someone to review it before merging. Until then, enjoy! I think I've found a way to make the DPI scaling work as well. More info here: #1612 |
While this feature is part of other branches for testing EGFX integration, it somehow never made it into devel. This should fix neutrinolabs#1928, for real this time!
I have two monitors with 2560x1440 and 1920x1080 resolution.
and setting mstsc to use one monitor for full screen mode.
when I drag mstsc from a monitor to another, error occurred as below.
It means internal error.
and will got log
The text was updated successfully, but these errors were encountered: