Remmina crashes on incoming Desktop Screen sharing

[xnandersson]

Trying to accept incoming Desktop Screen Share Pidgin -> Pidgin.

This trace is left in the gdb-remmina debugger.

(gdb) thread apply all bt full

Thread 4 (Thread 0x7fffde3cf700 (LWP 3421)):
#0  0x00007ffff27efe8d in poll () at ../sysdeps/unix/syscall-template.S:84
No locals.
#1  0x00007ffff6f0631c in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#2  0x00007ffff6f066a2 in g_main_loop_run ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#3  0x00007ffff6c18906 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
No symbol table info available.
#4  0x00007ffff6f2cb45 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#5  0x00007ffff382c6fa in start_thread (arg=0x7fffde3cf700)
    at pthread_create.c:333
        __res = <optimized out>
        pd = 0x7fffde3cf700
        now = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140736921925376, 
                4726757176775011656, 0, 140736938707007, 140736921926080, 
                140736817338400, -4726689565799879352, -4726748130810663608}, 
              mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, 
            data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#6  0x00007ffff27fbb5d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
No locals.

Thread 3 (Thread 0x7fffdebd0700 (LWP 3420)):
#0  0x00007ffff27efe8d in poll () at ../sysdeps/unix/syscall-template.S:84
No locals.
#1  0x00007ffff6f0631c in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#2  0x00007ffff6f0642c in g_main_context_iteration ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#3  0x00007ffff6f06469 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#4  0x00007ffff6f2cb45 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#5  0x00007ffff382c6fa in start_thread (arg=0x7fffdebd0700)
    at pthread_create.c:333
        __res = <optimized out>
        pd = 0x7fffdebd0700
        now = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140736930318080, 
                4726757176775011656, 0, 140736938706655, 140736930318784, 0, 
                -4726688465751380664, -4726748130810663608}, 
              mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, 
            data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#6  0x00007ffff27fbb5d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
No locals.

Thread 2 (Thread 0x7fffdf3d1700 (LWP 3419)):
#0  0x00007ffff27efe8d in poll () at ../sysdeps/unix/syscall-template.S:84
No locals.
#1  0x00007ffff6f0631c in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#2  0x00007ffff6f0642c in g_main_context_iteration ()
---Type <return> to continue, or q <return> to quit---
  /libglib-2.0.so.0
No symbol table info available.
#3  0x00007fffdf3d928d in ?? () from /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
No symbol table info available.
#4  0x00007ffff6f2cb45 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#5  0x00007ffff382c6fa in start_thread (arg=0x7fffdf3d1700) at pthread_create.c:333
        __res = <optimized out>
        pd = 0x7fffdf3d1700
        now = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140736938710784, 4726757176775011656, 0, 140737488342207, 140736938711488, 7101552, -4726687367850365624, -4726748130810663608}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, 
              canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#6  0x00007ffff27fbb5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
No locals.

Thread 1 (Thread 0x7ffff7f0aa80 (LWP 3415)):
#0  0x00007ffff27efe8d in poll () at ../sysdeps/unix/syscall-template.S:84
No locals.
#1  0x00007ffff6f0631c in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#2  0x00007ffff6f066a2 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#3  0x00007ffff76b96f5 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
No symbol table info available.
#4  0x0000000000417744 in main (argc=1, argv=0x7fffffffde78) at /build/remmina-iNS5MV/remmina-1.1.2/remmina/src/remmina.c:303
        app = 0x700970
        app_class = <optimized out>
        status = 0
(gdb) 

[xhaakon]

I've seen remmina crashing randomly when the session was connected through a relay. This might be a possible effect of that long-standing TURN server issue - I imagine the relay discards some packet here and there and thus freerdp receives garbage data it can't process.

Do you happen to have Pidgin log for this?

[xhaakon]

In order to move on with this bug, we need Pidgin log showing how the data connection was established.

[tcprdg]

I'm also affected by this issue intermittently. Also, sometimes when it works, it takes a lot of time loading the screen and eventually ends up not loading it

[xhaakon]

@tcprdg This really looks more like a problem with creating a connection to the other participant, which depends on may factors including whether you're connected from within you company network or from an open internet, where your peer is located, (im)possibility of direct TCP link between the participants due to NAT or firewall restrictions, if you and your peer belong to the same domain, etc.

In order for us to be able to know more about your particular problem, please create a log during your desktop sharing session using pidgin run with the following arguments:

G_MESSAGES_DEBUG=all NICE_DEBUG=all,libnice-nice-verbose pidgin --debug |& tee ~/pidgin.log

[xhaakon]

Btw. the stack trace doesn't show any crash, just four threads sleeping in poll() and waiting for input.

[tcprdg]

@xhaakon thanks for the detailed explanation. Will do!

[tcprdg]

Hi @xhaakon , just tried a peer to peer connection and sharing (both ways) with my colleague who is sitting next to me (meaning, we both are using wired connection and part of same domain) and didn't notice the issue.

The instance that I mentioned above in my previous post was when I share desktop (or view theirs) with colleagues in remote site who are our contractors and they get into our company network via VPN connection. And they all are using windows with microsoft lync 2013.

You may be right. Presuming so, is there a workaround to prevent the crash? Or its a bug with no workaround and needs a proper fix for this scenario?

[xhaakon]

@tcprdg What you have described definitely points to a connectivity issue.

colleagues in remote site who are our contractors and they get into our company network via VPN

So I assume they have their Lync accounts in the same domain as is yours, right?

Is there a workaround to prevent the crash? Or its a bug with no workaround and needs a proper fix for this scenario?

I can't really say unless I see some Pidgin logs from your scenario. I already wrote how to do it.

What may work as an interim solution is creating a multi-user conference instead of attempting peer-to-peer connection with your colleague over a VPN: Look up your colleague in Pidgin's Buddy List, right-click and select "New chat" (Pidgin will pop up new conversation window). Then let your colleague share their desktop not with you, but with this meeting. You can also add audio or share your own desktop - see the conversation window's menu items in "Conversation > More":

This will force the data traffic to flow through an intermediary conferencing server, which on one hand is unnecessary ineffective for just two-party conversations, but the odds are Pidgin will be able to connect to that server inside your company even though it isn't able to reach the person behind a VPN tunnel.

[xhaakon]

@tcprdg Just realized the above won't work when meeting is initialized from Pidgin due to #35. I think it should be quite an easy fix and will look into it during today.

Still, your colleague with Lync can create the meeting, invite you and then share their desktop. That should work:

The menu opens using that gear wheel icon on the right.

[xhaakon]

@tcprdg I've fixed #35. If you update pidgin-sipe at least to version mentioned here, desktop sharing should work event when you create the meeting yourself.

[tcprdg]

Upgraded, testing today.

[tcprdg]

Hi @xhaakon After upgrading, i tried joining the same conference that has issues ( i have a daily meeting with contractors, who has same domain email address as me, and one of the contractors has created the Lync bridge that I join for audio and desktop sharing). They (the contractors) all join into our company network through some mechanism (i.e. a tunnel is setup for them to come into our company network) which I like to simplify as 'over vpn'.

So, today in that conference, we all joined in chat (and i used a separate physical phone to join audio and not pidgin) and after some time, one of the contractors started presenting. I accepted the share and the screen felt like it started loading, but after a long wait it gave up stating some error (that I dont remember now, but it had 127.0.0.1 ip address in that error message). Then, I tried Conversation->more->show presentation and at that time pidgin crashed. I had started the pidgin the way you mentioned above and have logs in a file called pidgin.log

I did scrub the log myself but it contains lots of details such as my email address,my contacts email addresses, our company server names, IP Addresses etc. I am not comfortable sharing them as is. If you could tell me what particular debug lines you are looking for, I can grep them, paste them in a notepad and attach it.

Please let me know.

[xhaakon]

I am not comfortable sharing them as is. If you could tell me what particular debug lines you are looking for, I can grep them, paste them in a notepad and attach it.

@tcprdg Well, it's not easy to tell what parts of the log are important with regard to this issue. Generally any lines with private data are almost certainly irrelevant and you can discard them. Server names and domains can be searched and replaced with something generic like '@company.com' relatively easily in common text editors.

Instead of posting the log publicly here, you may send it (compressed, please) to the email in the details of my github account.

If you insist on not sharing the full log with anyone, look for the parts that contain information about negotiating the connection (search e.g. a=candidate):

v=0
o=- 0 0 IN IP4 1.2.3.4
s=session
c=IN IP4 1.2.3.4
b=CT:99980
t=0 0
m=audio 20006 RTP/SAVP 0 3 8 9 10 14 96 97 98 99 100 101 102 103 104
a=candidate:1 1 UDP 2028994815 1.2.3.4 20006 typ host 
a=candidate:1 2 UDP 2028994814 1.2.3.4 20003 typ host 
a=candidate:2 1 TCP-ACT 1013580031 1.2.3.4 20005 typ host 
a=candidate:2 2 TCP-ACT 1013580031 1.2.3.4 20005 typ host 
a=candidate:3 1 TCP-PASS 1013186815 1.2.3.4 20005 typ host 
a=candidate:3 2 TCP-PASS 1013186815 1.2.3.4 20005 typ host 
a=candidate:7 1 UDP 183501055 5.6.7.8 54133 typ relay raddr 1.2.3.4 rport 20006
a=candidate:7 2 UDP 183501054 5.6.7.8 55959 typ relay raddr 1.2.3.4 rport 20003
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:4+ubID93MHhuvA5MvKnR4iAi1MG9IYlgPWHpfYAx|2^31
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:10 L16/44100
a=rtpmap:14 MPA-ROBUST/90000
a=rtpmap:96 OPUS/48000
a=rtpmap:97 SIREN/16000
a=fmtp:97 bitrate=16000
a=rtpmap:98 G726-16/8000
a=rtpmap:99 AMR/8000
a=fmtp:99 octet-align=1 crc=0 robust-sorting=0 interleaving=0
a=rtpmap:100 telephone-event/48000
a=fmtp:100 events=0-15
a=rtpmap:101 telephone-event/16000
a=fmtp:101 events=0-15
a=rtpmap:102 telephone-event/8000
a=fmtp:102 events=0-15
a=rtpmap:103 telephone-event/90000
a=fmtp:103 events=0-15
a=rtpmap:104 telephone-event/44100
a=fmtp:104 events=0-15
a=rtcp:20003
a=ice-ufrag:KrYE
a=ice-pwd:mZwnBtS4liv14F7rzKW6j9

Also let us see the last dozen or so lines in the file, which contain messages from just prior the crash.

In case Pidgin crashes during your next meeting, you should also run it in a debugger so that you're able to capture a stack trace - that would be in fact the most helpful instrument for investigating the crash. See in the wiki how to launch Pidgin in gdb. Don't forget to install the listed -dbg packages, otherwise the stack trace won't be very useful.

[xhaakon]

i used a separate physical phone to join audio and not pidgin

You might have done that on purpose, but in case you don't know, you can join meeting audio from Pidgin's "Conversation > More" menu (see the screenshot in one of my previous posts).

[xhaakon]

@xnandersson I've put new Remmina into the PPA. Please check if you still see crashes on your laptop.

[xnandersson]

@xhaakon Sure! I'll try it tomorrow! Great :-)

[xhaakon]

@xnandersson Can you confirm that Remmina on your laptop no longer crashes when you connect to a conference?

[xhaakon]

@xnandersson Ping. Can you please re-test this ^^^^.

[tcprdg]

Hi, sorry for getting back late. I'm off since few days, didnt check these. In the last 10 days, I see that i haven't seen the crash. Looks good

[xhaakon]

Since I can't reproduce this crash and those who opened the issue haven't reported any problems for a while, I'm closing the ticket.