remmina dumps core

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

remmina dumps core

Bryan Vyhmeister-3
I have unable to get remmina to work well for quite a while. I try to
connect to various macOS machines and I just get an "Abort trap (core
dumped)." I must not be the only one seeing these errors. I like remmina
only because I can connect to macOS machines without setting a separate
VNC password. Has anyone else seen these issues? I can use ssvnc with
good success as long as I set a specific VNC password.

I am having problems on a Kaby Lake ThinkPad X270 and Skylake NUC6i7KYK.
Both are using inteldrm(4). I am happy to provide any further debugging
information if that would be helpful. I can also try on some other
machines with Haswell graphics if that would help any.

Bryan

Reply | Threaded
Open this post in threaded view
|

Re: remmina dumps core

Stuart Henderson
A backtrace from gdb would be a good start. Is there anything in dmesg at
the time of the crash?

--
Sent from a phone, apologies for poor formatting.

On 9 July 2018 01:53:33 Bryan Vyhmeister <[hidden email]> wrote:

> I have unable to get remmina to work well for quite a while. I try to
> connect to various macOS machines and I just get an "Abort trap (core
> dumped)." I must not be the only one seeing these errors. I like remmina
> only because I can connect to macOS machines without setting a separate
> VNC password. Has anyone else seen these issues? I can use ssvnc with
> good success as long as I set a specific VNC password.
>
> I am having problems on a Kaby Lake ThinkPad X270 and Skylake NUC6i7KYK.
> Both are using inteldrm(4). I am happy to provide any further debugging
> information if that would be helpful. I can also try on some other
> machines with Haswell graphics if that would help any.
>
> Bryan



Reply | Threaded
Open this post in threaded view
|

Re: remmina dumps core

Ryan Freeman
In reply to this post by Bryan Vyhmeister-3
On Sun, Jul 08, 2018 at 05:53:16PM -0700, Bryan Vyhmeister wrote:

> I have unable to get remmina to work well for quite a while. I try to
> connect to various macOS machines and I just get an "Abort trap (core
> dumped)." I must not be the only one seeing these errors. I like remmina
> only because I can connect to macOS machines without setting a separate
> VNC password. Has anyone else seen these issues? I can use ssvnc with
> good success as long as I set a specific VNC password.
>
> I am having problems on a Kaby Lake ThinkPad X270 and Skylake NUC6i7KYK.
> Both are using inteldrm(4). I am happy to provide any further debugging
> information if that would be helpful. I can also try on some other
> machines with Haswell graphics if that would help any.
>
> Bryan
>

At least I can say I use remmina every day at work and i don't see this
issue, with a snapshot from jul 2.  However, I only use it for rdp, not
VNC.  Therefore it does seem specific to remmina's VNC support?

Reply | Threaded
Open this post in threaded view
|

Re: remmina dumps core

Bryan Vyhmeister-3
In reply to this post by Stuart Henderson
On Mon, Jul 09, 2018 at 12:39:43PM +0100, Stuart Henderson wrote:
> A backtrace from gdb would be a good start. Is there anything in dmesg at
> the time of the crash?

Nothing in dmesg. The output if I run in an xterm and also the backtrace
are below. I should also mention that I am using cwm and not any desktop
environment. Thank you.

Bryan



$ remmina                                                                

** (remmina:40021): CRITICAL **: 10:27:11.944: secret_service_load_collections_sync: assertion 'paths != NULL' failed
[glibsecret] unable to get secret service: Unknown error.
Plugin entry returned false: /usr/local/lib/remmina/plugins/remmina-plugin-secret.so.
StatusNotifier/Appindicator support: not supported by desktop. Remmina will try to fallback to GtkStatusIcon/xembed
WARNING: Remmina is running with a secret plugin, but it cannot connect to a secret service.

(remmina:40021): Gtk-WARNING **: 10:27:12.108: gtk_menu_attach_to_widget(): menu already attached to GtkMenuItem
Gtk-Message: 10:27:16.253: GtkDialog mapped without a transient parent. This is discouraged.
pthread_mutex_destroy on mutex with waiters!
pthread_mutex_destroy on mutex with waiters!
pthread_mutex_destroy on mutex with waiters!
pthread_mutex_destroy on mutex with waiters!
Abort trap (core dumped)
$



(gdb) bt
#0  thrkill () at -:3
#1  0x00001c9f16420e9e in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51
#2  0x00001c9f16439a56 in _rthread_mutex_timedlock (mutexp=Variable "mutexp" is not available.
)
    at /usr/src/lib/libc/thread/rthread_mutex.c:118
#3  0x00001c9ed6791f77 in onMainThread_schedule_callback_and_wait ()
   from /usr/local/lib/remmina/plugins/remmina-plugin-vnc.so
#4  0x00001c9ed6791ddb in remmina_plugin_vnc_update_scale ()
   from /usr/local/lib/remmina/plugins/remmina-plugin-vnc.so
#5  0x00001c9ed67907d9 in remmina_plugin_vnc_rfb_allocfb ()
   from /usr/local/lib/remmina/plugins/remmina-plugin-vnc.so
#6  0x00001c9ec90eb972 in rfbInitClient () from /usr/local/lib/libvncclient.so.0.0
#7  0x00001c9ed678f922 in remmina_plugin_vnc_main ()
   from /usr/local/lib/remmina/plugins/remmina-plugin-vnc.so
#8  0x00001c9ed678f43b in remmina_plugin_vnc_main_thread ()
   from /usr/local/lib/remmina/plugins/remmina-plugin-vnc.so
#9  0x00001c9f387cfbfe in _rthread_start (v=Variable "v" is not available.
)
    at /usr/src/lib/librthread/rthread.c:96
#10 0x00001c9f164810db in __tfork_thread ()
    at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:75
#11 0x0000000000000000 in ?? ()
Current language:  auto; currently asm

Reply | Threaded
Open this post in threaded view
|

Re: remmina dumps core

Bryan Vyhmeister-3
In reply to this post by Ryan Freeman
On Mon, Jul 09, 2018 at 10:12:42AM -0700, Ryan Freeman wrote:
> At least I can say I use remmina every day at work and i don't see this
> issue, with a snapshot from jul 2.  However, I only use it for rdp, not
> VNC.  Therefore it does seem specific to remmina's VNC support?

That's good to hear. I presume others are not running into this or more
would mention it. This has been happening for a little while now under a
variety of snapshots. I am running the July 8 snapshot at the moment. I
don't use remmina that often so have not reported it until now because I
thought perhaps it was due to some transient issue but the problem still
remains.

I am using only a very basic host config. Protocol: VNC - VNC viewer,
Server, User name, and User password. Setting Color depth or Quality
does not seem to have any effect.

I just tried to connect to a macOS 10.12.6 system as well as a macOS
10.13.5 system with the same result. It is working far enough down the
connection to wake up the screen of the system I am connecting to
though. The backtrace and other info are in my other message to the
list.

Bryan

Reply | Threaded
Open this post in threaded view
|

Re: remmina dumps core

Stuart Henderson
In reply to this post by Bryan Vyhmeister-3
On 2018/07/09 10:31, Bryan Vyhmeister wrote:

> On Mon, Jul 09, 2018 at 12:39:43PM +0100, Stuart Henderson wrote:
> > A backtrace from gdb would be a good start. Is there anything in dmesg at
> > the time of the crash?
>
> Nothing in dmesg. The output if I run in an xterm and also the backtrace
> are below. I should also mention that I am using cwm and not any desktop
> environment. Thank you.
>
> Bryan
>
>
>
> $ remmina                                                                
>
> ** (remmina:40021): CRITICAL **: 10:27:11.944: secret_service_load_collections_sync: assertion 'paths != NULL' failed
> [glibsecret] unable to get secret service: Unknown error.
> Plugin entry returned false: /usr/local/lib/remmina/plugins/remmina-plugin-secret.so.
> StatusNotifier/Appindicator support: not supported by desktop. Remmina will try to fallback to GtkStatusIcon/xembed
> WARNING: Remmina is running with a secret plugin, but it cannot connect to a secret service.
>
> (remmina:40021): Gtk-WARNING **: 10:27:12.108: gtk_menu_attach_to_widget(): menu already attached to GtkMenuItem
> Gtk-Message: 10:27:16.253: GtkDialog mapped without a transient parent. This is discouraged.
> pthread_mutex_destroy on mutex with waiters!
> pthread_mutex_destroy on mutex with waiters!
> pthread_mutex_destroy on mutex with waiters!
> pthread_mutex_destroy on mutex with waiters!
> Abort trap (core dumped)
> $
>
>
>
> (gdb) bt
> #0  thrkill () at -:3
> #1  0x00001c9f16420e9e in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51
> #2  0x00001c9f16439a56 in _rthread_mutex_timedlock (mutexp=Variable "mutexp" is not available.
> )
>     at /usr/src/lib/libc/thread/rthread_mutex.c:118
> #3  0x00001c9ed6791f77 in onMainThread_schedule_callback_and_wait ()
>    from /usr/local/lib/remmina/plugins/remmina-plugin-vnc.so
> #4  0x00001c9ed6791ddb in remmina_plugin_vnc_update_scale ()
>    from /usr/local/lib/remmina/plugins/remmina-plugin-vnc.so
> #5  0x00001c9ed67907d9 in remmina_plugin_vnc_rfb_allocfb ()
>    from /usr/local/lib/remmina/plugins/remmina-plugin-vnc.so
> #6  0x00001c9ec90eb972 in rfbInitClient () from /usr/local/lib/libvncclient.so.0.0
> #7  0x00001c9ed678f922 in remmina_plugin_vnc_main ()
>    from /usr/local/lib/remmina/plugins/remmina-plugin-vnc.so
> #8  0x00001c9ed678f43b in remmina_plugin_vnc_main_thread ()
>    from /usr/local/lib/remmina/plugins/remmina-plugin-vnc.so
> #9  0x00001c9f387cfbfe in _rthread_start (v=Variable "v" is not available.
> )
>     at /usr/src/lib/librthread/rthread.c:96
> #10 0x00001c9f164810db in __tfork_thread ()
>     at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:75
> #11 0x0000000000000000 in ?? ()
> Current language:  auto; currently asm
>

No idea about a fix but here are some more details,

The SIGABRT comes from the mutex checking that we have in librthread. The actual
line is here:

249         if (mutex->owner != self) {
250         _rthread_debug(5, "%p: different owner %p (%p)\n", self, (void *)mutex,
251             (void *)mutex->owner);
252                 if (mutex->type == PTHREAD_MUTEX_ERRORCHECK ||
253                     mutex->type == PTHREAD_MUTEX_RECURSIVE) {
254                         return (EPERM);
255                 } else {
256                         /*
257                          * For mutex type NORMAL our undefined behavior for
258                          * unlocking an unlocked mutex is to succeed without
259                          * error.  All other undefined behaviors are to
260                          * abort() immediately.
261                          */
262                         if (mutex->owner == NULL &&
263                             mutex->type == PTHREAD_MUTEX_NORMAL)
264                                 return (0);
265                         else
266>>>                              abort();
267
268                 }
269         }

I've tried forcgin the mutex to PTHREAD_MUTEX_NORMAL rather than the
default PTHREAD_MUTEX_STRICT_NP with the diff below but it still aborts,
the reason being that mutex->owner != NULL (and actually running with
RTHREAD_DEBUG=5 we see the "different owner" message).

Index: plugins/vnc/vnc_plugin.c
--- plugins/vnc/vnc_plugin.c.orig
+++ plugins/vnc/vnc_plugin.c
@@ -175,11 +175,15 @@ static void onMainThread_cleanup_handler( gpointer dat
 
 static void onMainThread_schedule_callback_and_wait( struct onMainThread_cb_data *d )
 {
+ pthread_mutexattr_t mattr;
  TRACE_CALL(__func__);
  d->cancelled = FALSE;
  pthread_cleanup_push( onMainThread_cleanup_handler, d );
- pthread_mutex_init( &d->mu, NULL );
- pthread_mutex_lock( &d->mu );
+ pthread_mutexattr_init(&mattr);
+ pthread_mutexattr_settype(&mattr, PTHREAD_MUTEX_NORMAL);
+ pthread_mutex_init( &d->mu, &mattr );
+ pthread_mutexattr_destroy(&mattr);
+ pthread_mutex_lock(&d->mu);
  gdk_threads_add_idle( (GSourceFunc)onMainThread_cb, (gpointer)d );
 
  pthread_mutex_lock( &d->mu );


Not sure where to go next but maybe this will save somebody else some time..

Reply | Threaded
Open this post in threaded view
|

Re: remmina dumps core

Bryan Vyhmeister-3
On Mon, Jul 09, 2018 at 11:20:43PM +0100, Stuart Henderson wrote:
> No idea about a fix but here are some more details,

Thanks for taking the time to look at it further. Hopefully someone who
might have an idea can chime in.

Bryan

Reply | Threaded
Open this post in threaded view
|

Re: remmina dumps core

Ales Tepina
In reply to this post by Bryan Vyhmeister-3
On Sun, Jul 08, 2018 at 05:53:16PM -0700, Bryan Vyhmeister wrote:

> I have unable to get remmina to work well for quite a while. I try to
> connect to various macOS machines and I just get an "Abort trap (core
> dumped)." I must not be the only one seeing these errors. I like remmina
> only because I can connect to macOS machines without setting a separate
> VNC password. Has anyone else seen these issues? I can use ssvnc with
> good success as long as I set a specific VNC password.
>
> I am having problems on a Kaby Lake ThinkPad X270 and Skylake NUC6i7KYK.
> Both are using inteldrm(4). I am happy to provide any further debugging
> information if that would be helpful. I can also try on some other
> machines with Haswell graphics if that would help any.
>
> Bryan
>

I have the exact same problem on my T470 running current. No matter what setting i try when i try to connect to Proxmox VM running OS X (Mojave), it dumps core.
ssvnc works fine.

Ales