Memory protection violation

Hello x6543,

Can you please tell us what is your desktop environment?

We will try to reproduce your issue and investigate in the latest version of RDM.

Regards,

Openbox is not quite "Desktop env".

To be more specific: Mabox distro -> based on Manjaro.


Please just run RDM free from repo on Manjaro or Mabox, and see what happens.

I'm not using wine for runnig rdm.

More specs:
This happens after few seconds of vnc connection is initialized using pivoting to remote connected host and his 127.0.0.1:5901 vnc port.

Thank you for the additional information. We'll let you know when we have update on this issue.

Regards,

Hi x6543,

I installed Mabox based on Manjaro and I can't reproduce the issue with the free version (2022.2.2.7).

I would like to simulate your environment, can you please give me more information about your pivoting setup?

Regards,

ssh IP -l user -p PORT -L 5905:127.0.0.1:5901 -N

This is for connection to VNC on remote host on port 5901.
This works fine with KRDC and vncviewer.

On RDM.free I just set vnc session as: 127.0.0.1 port 5905 and password. That's it.
VNC starting, remote screen shows up... few seconds later.... memory protection....

Visualisation:
https://we.tl/t-3gB5uYRBdl?utm_campaign=TRN_TDL_05&utm_source=sendgrid&utm_medium=email&trk=TRN_TDL_05

Hi x6543,

We were able to reproduce this pivoting setup, but not to reproduce the crash.

Just before running remotedesktopmanager.free, please execute this command so we can have more logs:
export WLOG_LEVEL=DEBUG

And can you tell us which VNC Server application you are using?

Regards,

Xvnc TigerVNC 1.11.0 - built 2022-01-26 17:59 @ Debian 11 (64bit)

[t@computer ~]$ export WLOG_LEVEL=DEBUG
[t@computer ~]$ remotedesktopmanager.free 

(RemoteDesktopManager.Free:164748): Gtk-CRITICAL **: 18:22:46.904: gtk_widget_grab_default: assertion 'gtk_widget_get_can_default (widget)' failed

(RemoteDesktopManager.Free:164748): Gdk-CRITICAL **: 18:22:48.164: gdk_window_thaw_toplevel_updates: assertion 'window->update_and_descendants_freeze_count > 0' failed

(RemoteDesktopManager.Free:164748): GLib-GObject-CRITICAL **: 18:22:52.472: g_object_remove_toggle_ref: assertion 'G_IS_OBJECT (object)' failed
[18:22:54:802] [164748:164780] [DEBUG][freevnc] - << ServerProtocolVersion: RFB 003.008
[18:22:54:802] [164748:164780] [DEBUG][freevnc] - >> ClientProtocolVersion: RFB 003.008
[18:22:54:805] [164748:164780] [DEBUG][freevnc.auth] - numberOfSecurityTypes: 1
[18:22:54:805] [164748:164780] [DEBUG][freevnc.auth] - 	[0] VNC (2)
[18:22:54:814] [164748:164780] [DEBUG][freevnc.auth] - << AuthStatus: 0
[18:22:54:814] [164748:164780] [DEBUG][freevnc] - >> RfbClientInit: SHARED (0x01)
[18:22:54:817] [164748:164780] [DEBUG][freevnc] - << RfbServerInit: 1918x1128 name: debian64:1 (tuser)
[18:22:54:817] [164748:164780] [DEBUG][freevnc] - << RfbServerInit: PixelFormat: bitsPerPixel: 32 depth: 24 bigEndian: 0 trueColor: 1 R: 255/16 G: 255/8 B: 255/0
[18:22:54:817] [164748:164780] [DEBUG][freevnc] - >> RfbSetEncodings: numberOfEncodings: 12
[18:22:54:817] [164748:164780] [DEBUG][freevnc] - 	[0]: Hextile (5)
[18:22:54:817] [164748:164780] [DEBUG][freevnc] - 	[1]: CopyRect (1)
[18:22:54:817] [164748:164780] [DEBUG][freevnc] - 	[2]: ZRLE (16)
[18:22:54:817] [164748:164780] [DEBUG][freevnc] - 	[3]: Tight (7)
[18:22:54:817] [164748:164780] [DEBUG][freevnc] - 	[4]: Zlib (6)
[18:22:54:817] [164748:164780] [DEBUG][freevnc] - 	[5]: Unknown (0)
[18:22:54:817] [164748:164780] [DEBUG][freevnc] - 	[6]: CursorImage (-239)
[18:22:54:817] [164748:164780] [DEBUG][freevnc] - 	[7]: CursorImageAlpha (1104)
[18:22:54:817] [164748:164780] [DEBUG][freevnc] - 	[8]: VncCursorPosition (-232)
[18:22:54:817] [164748:164780] [DEBUG][freevnc] - 	[9]: DesktopSize (-223)
[18:22:54:817] [164748:164780] [DEBUG][freevnc] - 	[10]: ZlibCompression (-250)
[18:22:54:817] [164748:164780] [DEBUG][freevnc] - 	[11]: JpegQuality (-26)
[18:22:54:817] [164748:164780] [DEBUG][freevnc] - >> RfbFramebufferUpdateRequest: incremental: 0 x: 0 y: 0 width: 1918 height: 1128
[18:22:54:871] [164748:164991] [DEBUG][freevnc] - << CursorImage: pixelSize: 0 bitmaskSize: 0
[18:22:54:917] [164748:164991] [DEBUG][freevnc] - >> RfbFramebufferUpdateRequest: incremental: 1 x: 0 y: 0 width: 1918 height: 1128
[18:22:55:573] [164748:164991] [DEBUG][freevnc] - >> RfbFramebufferUpdateRequest: incremental: 1 x: 0 y: 0 width: 1918 height: 1128
[18:22:55:235] [164748:164748] [DEBUG][freevnc] - >> RfbPointerEvent: buttons: 0 x: 99 y: 91
[18:22:55:239] [164748:164991] [DEBUG][freevnc] - << CursorImage: pixelSize: 1260 bitmaskSize: 42
[18:22:55:239] [164748:164991] [DEBUG][freevnc] - >> RfbFramebufferUpdateRequest: incremental: 1 x: 0 y: 0 width: 1918 height: 1128
[18:22:55:243] [164748:164748] [DEBUG][freevnc] - >> RfbPointerEvent: buttons: 0 x: 95 y: 89
[18:22:55:243] [164748:164991] [DEBUG][freevnc] - << CursorImage: pixelSize: 1260 bitmaskSize: 42
Naruszenie ochrony pamięci (zrzut pamięci)
[t@computer ~]$ 

Hi x6543,

Thanks for the extra information. A memory access violation is a serious bug either in our VNC integration, or inside RDM itself. However, it will be really tricky to resolve this if we can't reproduce or at least narrow down the problem.

The output from your log looks normal, and some basic testing with TigerVNC doesn't crash on my side (as Gabriel already wrote).

I'd like to ask for some further information, if possible:

• What does your xvnc configuration look like? I want to run my server with the same parameters as you are using
• Inside RDM, what do you have configured for the session under VNC > Advanced (specifically, the options for mouse cursor and encoding)

Furthermore - have you tested with any other VNC server? From your video, it looks like we crash decoding a screen update. If this works well with another server, it might tell us if the issue is inside the image decoder or the renderer.

Please don't hesitate to post back if something is not clear or you have some questions.

Thanks and kind regards,

This is my script for starting vnc service:

#!/bin/bash
echo passwordUserRunningVncService | su UserRunningVncService -c "vncserver -rfbport 5901 -localhost yes -geometry 1920x1080 -alwaysshared -passwd /home/UserRunningVncService/.vnc/passwd"
#EOF

VNC->Advanced are default. (Look at attached screen).
Works well with many other vnc clients with pivoting via ssh, including RDM free Windows version.
This happens only on Mabox (and perhaps on Manjaro).
RDM free are installed from Arch repository.
I'll try to reproduce this bug on other Linux distro, in few days.

Hello again

Thanks for the extra info. I'll work on reproducing your setup.

In the meantime, the error message you get "(zrzut pamięci)" - if I run through Google Translate, it tells me "memory dump". I wonder if that's the same as a core dump?

If you run `coredumpctl list`, are there core dumps for RDM?

I'm not too familiar with `coredumputil`, but if you have memory dumps you can try to export the most recent one:

`coredumpctl -o rdm.coredump dump /path/to/remotedesktopmanager`

If you manage to export one or more memory dumps, that could be very helpful to us. In this case, please don't upload to the forum but instead, send to support@devolutions.net (mentioning this forum thread in the email so it finds it's way to us).

Any questions or problems please let me now!

Kind regards,

Done.

Edited: the same memory protection violation is on Ubuntu 22.10 and RDM free installed via deb (version 2022.3.0.5), with the same vnc settings.

Tested with TightvncServer running on Windows 10: works ok, with and without pivoting.

It looks like, RDM doesn't like Xtigervnc.

Hello again

Thanks for the additional tests. It's extremely strange, because I have no trouble connecting to Tiger servers from RDM on Linux.

I hope that the core dump will reveal something; I have to wait for the file(s) to be forwarded onto me by our support team. Thank you for your patience, I'll post back here once I've taken a look.

Kind regards,

Hello again

I'm afraid I wasn't able to extract too much from the core dump, except for a couple of small clues.

I've sent you a direct message via the forum with an additional test to try, if you don't mind.

Please let me know any questions or problems.

Thanks and kind regards,

Hello again

Thanks for testing with the executable that I sent to you. It demonstrates that our native VNC module is able to connect to your server and function properly. Ergo, the issue must exist inside RDM.

I'm looking at the integration between RDM Linux and the VNC module to try and spot what the problem might be.

In the meantime, if you manage to set up a VM with same OS version and tigervnc; it will be very revealing if you have the same issue with that environment.

I'll post back once I have an update on my side.

Thanks for your patience, and kind regards

Hi again.
I think, I got this VMs done.
Tested. But this time error is not "memory protect violation" but just "terminate" with (dump core).
I got 2 VMs prepared.
Edit:
Just tested again and "memory protect violation" shows up.
This is not only Mabox/Manjaro problem, as I think before.
I got client RDM on Ubuntu 22.10 VM and vnc server is on Debian 11 64bit VM.

Hello

Thanks for taking the time and the additional troubleshooting.

I have some ideas for areas that could be improved in the relevant code, but it's hard to make broad changes without reproducing the problem, The VMs that you sent will be very helpful. I have to involve my IT team to get that hosted in a lab so I appreciate your patience while we continue looking into this. I'll post back here once I have some information.

Thanks again and kind regards,

Hello again

Thank you for the help debugging and your patience with this. I was able to understand the problem and submitted fixes to the RDM Linux team.

I'll try to update this post once the fixes are available (I'm not on the RDM Linux team so I'm unsure of their release schedule, but we do have a ticket open to track the issue).

Thanks again and kind regards,

Hi.
I'm glad to be useful.
Please take your time.

BTW. (offtopic):
I know the fact, Linux version of RDM is not on the top of priority list, but it would be nice, if The RDM Linux Team can make ssh shell/terminal font more eye friendly? I know this is depending on some library/font in system, but this fonts are just ugly, with no antialiasing.
Alternative of this is to use external terminal ex: terminator or urxvt, or whatever.

Thanks in advance. Best regards.

Hi x6543,

Actually, text anti-aliasing for terminal connections is possible as it was implemented a little while ago. It should be turned on by default, but, if this is not the case for you, you can enable it in Preferences > Session Type > Terminal.

I hope this helps.

Best regards

Hi x6543,

The fix for your VNC issue has been realesed (2022.3.0.7). Let us know if that works for you.

Regards,

Preferences > Session Type > Terminal.

Yes, I know. I helps a little bit. Thank You.

The fix for your VNC issue has been realesed (2022.3.0.7). Let us know if that works for you.

Wonderful message. You can count on my feedback. Thank You.

Hi again.
2022.3.0.8 linux version tested, and works IMHO faster, than Windows version.
VNC session still has a render glitches, but this is irrelevant.
Now I can write: this issue is now solved.
RDM works very well.
Thank You All for making this software better.

Best regards.
(Imho this topic can be closed.)

Hello again

Thank you for the positive feedback.

I noticed rendering glitches with VNC in RDM Linux while investigating this issue. I have an idea of the cause and opened a ticket on our side to improve the renderer. You can look for improvement in a future update although I don't have a timeline for that.

Thanks again and as always, don't hesitate to post back with further questions or concerns.

Kind regards,