After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 788648 - Settings app crashes when opening a VPN entry's settings
Settings app crashes when opening a VPN entry's settings
Status: RESOLVED DUPLICATE of bug 787893
Product: gnome-control-center
Classification: Core
Component: Network
3.26.x
Other Linux
: High critical
: ---
Assigned To: Control-Center Maintainers
Control-Center Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-10-07 23:19 UTC by rusins
Modified: 2017-10-08 16:30 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description rusins 2017-10-07 23:19:37 UTC
Pressing the little menu icon (icon with 3 horizontal stripes) sometimes crashes the settings app (about 70% of the time I would say). Doesn't depend on whether or not the selected VPN was turned on or not.


Console log when crash occurs:

(gnome-control-center:22769): GLib-GObject-CRITICAL **: g_type_instance_get_private: assertion 'instance != NULL && instance->g_class != NULL' failed

(gnome-control-center:22769): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
fish: “gnome-control-center” terminated by signal SIGSEGV (Address boundary error)


Running Gnome 3.26.1 on Arch Linux.
Comment 1 rusins 2017-10-07 23:28:56 UTC
Actually, I don't think I've managed to open up the VPN settings dialogue with the VPN turned off. So: when turned off, always crashes, when turned on, crashes most of the time.
Comment 2 André Klapper 2017-10-07 23:39:00 UTC
Thanks for taking the time to report this.
Without a stack trace from the crash it's very hard to determine what caused it.
Can you get us a stack trace with debug symbols? Please see https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces for more information on how to do so. Thanks in advance!
Comment 3 rusins 2017-10-08 01:09:05 UTC
Hmm, I'm afraid I might need a bit of help with the debugging process :D

So I got the following stack trace:

Thread 1 (Thread 0x7ffff7f3aa00 (LWP 2112))

  • #0 0x00007ffff2d54ca7 in
  • #1 ffi_call_unix64
  • #2 ffi_call
  • #3 g_cclosure_marshal_generic
  • #4 g_closure_invoke
  • #5 0x00007ffff08500b0 in
  • #6 g_signal_emitv
  • #7 0x00007ffff2daa46f in
  • #8 ffi_call_unix64
  • #9 ffi_call
  • #10 g_cclosure_marshal_generic
  • #11 g_closure_invoke
  • #12 0x00007ffff084fae2 in
  • #13 g_signal_emit_valist
  • #14 g_signal_emit_by_name
  • #15 0x00007ffff0b880f1 in
  • #16 0x00007ffff0b529d9 in
  • #17 g_main_context_dispatch
  • #18 0x00007ffff056df69 in
  • #19 g_main_context_iteration
  • #20 g_application_run
  • #21 main
    at main.c line 57

Now GDB gave me this when the app crashed:

Thread 1 "gnome-control-c" received signal SIGSEGV, Segmentation fault.
0x00007ffff2d54ca7 in ?? () from /usr/lib/libnm.so.0

As far as I understand, those two questionmarks indicate that I haven't enabled debugging support for libnm. libnm is part of the networkmanager package, so I downlaoded its sources, set the debug flags in its packagebuild, compiled and installed it, checked with GDB that the debug symbols weren't erased, yet it still shows those 2 question marks when crashing the settings app.

I'm guessing I'm missing something, and that debug flags for libnm need to be set somewhere else, but I don't know where :/ Any help would be appreciated! :)
Comment 4 rusins 2017-10-08 01:13:08 UTC
Nevermind, I'm an idiot :D I had installed the compiled networkmanager package, but didn't notice that I had also generated two libnm packages to install *faceplam*

Anyway, here is the stack trace (finally :D)

Thread 1 (Thread 0x7ffff7f3aa00 (LWP 2690))

  • #0 updated_cb
    at libnm/nm-remote-connection.c line 612
  • #1 ffi_call_unix64
  • #2 ffi_call
  • #3 g_cclosure_marshal_generic
  • #4 g_closure_invoke
  • #5 0x00007ffff08500b0 in
  • #6 g_signal_emitv
  • #7 nmdbus_settings_connection_proxy_g_signal
    at introspection/org.freedesktop.NetworkManager.Settings.Connection.c line 1754
  • #8 ffi_call_unix64
  • #9 ffi_call
  • #10 g_cclosure_marshal_generic
  • #11 g_closure_invoke
  • #12 0x00007ffff084fae2 in
  • #13 g_signal_emit_valist
  • #14 g_signal_emit_by_name
  • #15 0x00007ffff0b880f1 in
  • #16 0x00007ffff0b529d9 in
  • #17 g_main_context_dispatch
  • #18 0x00007ffff056df69 in
  • #19 g_main_context_iteration
  • #20 g_application_run
  • #21 main
    at main.c line 57

Hopefully this helps find the bug :)
Comment 5 Rui Matos 2017-10-08 16:30:18 UTC
looks like bug 787893 . re-open if it still happens after updating NM to a version that includes the fix

*** This bug has been marked as a duplicate of bug 787893 ***