Workaround for crashing Electron/Atom applications!

A few days ago  all my Electron (Atom Shell) apps started crashing on my Ubuntu 17.10  (Artful Aardvark) machine: Skype, Discord, Slack…  and each stack trace looks very much like this:

#0 0x0000000003419062 in ()
#1 0x0000000003f96086 in __start_google_malloc ()
#2 0x00000000034b9dc5 in calloc ()
#3 0x00007ffff20dc5d1 in g_malloc0 () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x00007ffff4afc4c9 in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#5 0x00007ffff4b01855 in g_type_register_static () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#6 0x00007ffff4b01af5 in g_type_register_static_simple () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#7 0x00007ffff5c93f24 in gdk_display_manager_get_type () at /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#8 0x00007ffff5c93f69 in gdk_display_manager_get () at /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#9 0x00007ffff6070954 in () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#10 0x00007ffff6056f28 in () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#11 0x00007ffff20e2fdf in g_option_context_parse () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x00007ffff6057538 in gtk_parse_args () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#13 0x00007ffff60575b9 in gtk_init () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#14 0x0000000001049626 in ()
#15 0x000000000104f1e7 in ()
#16 0x0000000001051656 in ()
#17 0x0000000003f6897b in brightray::BrowserMainParts::PreEarlyInitialization() ()
#18 0x0000000003e01169 in atom::AtomBrowserMainParts::PreEarlyInitialization() ()
#19 0x00000000015f6cf4 in ()

I don’t really know what’s on foot here, but Google led me to the GTK2_RC_FILES environment variable.

If I set this to empty, all these applications start properly!

Example starting Skype, note the space after the equals sign:

$ GTK2_RC_FILES= skypeforlinux

or

$ export GTK2_RC_FILES=
$ skypeforlinux

Can someone explain this error and what a proper fix would look like?

Update: Setting the XDG_CONFIG_DIRS environment variable to empty also works as a workaround!

2 thoughts on “Workaround for crashing Electron/Atom applications!”

  1. Stack trace from slack, with some debug symbols installed:

    (gdb) bt
    #0  0x00000000033aeacb in  ()
    #1  0x0000000003d05a78 in __start_google_malloc ()
    #2  0x00000000033a6023 in calloc ()
    #3  0x00007ffff1fb35d1 in g_malloc0 (n_bytes=80) at ../../../../glib/gmem.c:124
    #4  0x00007ffff4bdb4c9 in type_data_make_W ([email protected]=0x63cb20836c0, [email protected]=0x7fffffffd320, value_table=) at ../../../../gobject/gtype.c:1116
    #5  0x00007ffff4be0855 in g_type_register_static (parent_type=, type_name=0x7ffff5dc75f5 "GdkDisplayManager", [email protected]=0x7fffffffd320, [email protected]=(unknown: 0)) at ../../../../gobject/gtype.c:2766
    #6  0x00007ffff4be0af5 in g_type_register_static_simple ([email protected]=80, type_name=, [email protected]=144, [email protected]=0x7ffff5d72cc0 , [email protected]=24, [email protected]=0x7ffff5d72cb0 , flags=(unknown: 0)) at ../../../../gobject/gtype.c:2716
    #7  0x00007ffff5d72f24 in IA__gdk_display_manager_get_type () at ./gdk/gdkdisplaymanager.c:70
    #8  0x00007ffff5d72f69 in IA__gdk_display_manager_get () at ./gdk/gdkdisplaymanager.c:166
    #9  0x00007ffff614f954 in _gtk_modules_init (argc=0x0, argv=, gtk_modules_args=0x63cb2085780 "overlay-scrollbar:overlay-scrollbar:overlay-scrollbar:gail:atk-bridge") at ./gtk/gtkmodules.c:533
    #10 0x00007ffff6135f28 in do_post_parse_initialization (argc=0x0, argv=0x0) at ./gtk/gtkmain.c:789
    #11 0x00007ffff6135f28 in post_parse_hook (context=, group=, data=0x63cb2056460, error=0x7fffffffd4d0) at ./gtk/gtkmain.c:824
    #12 0x00007ffff1fb9fdf in g_option_context_parse ([email protected]=0x63cb2083660, [email protected]=0x7fffffffd514, [email protected]=0x7fffffffd518, [email protected]=0x7fffffffd4d0) at ../../../../glib/goption.c:2175
    #13 0x00007ffff6136538 in IA__gtk_parse_args (argc=0x7fffffffd514, argv=0x7fffffffd518) at ./gtk/gtkmain.c:981
    #14 0x00007ffff61365b9 in IA__gtk_init_check (argv=, argc=) at ./gtk/gtkmain.c:1017
    #15 0x00007ffff61365b9 in IA__gtk_init (argc=, argv=) at ./gtk/gtkmain.c:1067
    #16 0x000000000134c3b6 in  ()
    #17 0x000000000134493f in  ()
    #18 0x0000000001347366 in  ()
    #19 0x0000000003cd7adb in brightray::BrowserMainParts::PreEarlyInitialization() ()
    #20 0x0000000003b8a629 in atom::AtomBrowserMainParts::PreEarlyInitialization() ()
    #21 0x00000000017ee1cb in  ()
    #22 0x00000000017d76ff in  ()
    #23 0x000000000164dde8 in  ()
    #24 0x000000000134fe04 in  ()
    #25 0x0000000001350210 in  ()
    #26 0x0000000003b82e73 in main ()
    
  2. valgrind output:

    $ valgrind  --soname-synonyms=somalloc=*tcmalloc* `which slack`
    ==26032== Memcheck, a memory error detector
    ==26032== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
    ==26032== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
    ==26032== Command: /usr/bin/slack
    ==26032== 
    ==26037== Warning: bad signal number 65 in sigaction()
    ==26032== Invalid read of size 8
    ==26032==    at 0x33AEACB: ??? (in /usr/lib/slack/slack)
    ==26032==    by 0x3D05A77: ??? (in /usr/lib/slack/slack)
    ==26032==    by 0x33A6022: calloc (in /usr/lib/slack/slack)
    ==26032==    by 0xBCF25D0: g_malloc0 (gmem.c:124)
    ==26032==    by 0x91464C8: type_data_make_W (gtype.c:1116)
    ==26032==    by 0x914B854: g_type_register_static (gtype.c:2766)
    ==26032==    by 0x914BAF4: g_type_register_static_simple (gtype.c:2716)
    ==26032==    by 0x7F32F23: gdk_display_manager_get_type (gdkdisplaymanager.c:70)
    ==26032==    by 0x7F32F68: gdk_display_manager_get (gdkdisplaymanager.c:166)
    ==26032==    by 0x7A18953: _gtk_modules_init (gtkmodules.c:533)
    ==26032==    by 0x79FEF27: do_post_parse_initialization (gtkmain.c:789)
    ==26032==    by 0x79FEF27: post_parse_hook (gtkmain.c:824)
    ==26032==    by 0xBCF8FDE: g_option_context_parse (goption.c:2175)
    ==26032==  Address 0xffffffffffffe633 is not stack'd, malloc'd or (recently) free'd
    ==26032== 
    ==26032== 
    ==26032== Process terminating with default action of signal 11 (SIGSEGV)
    ==26032==  Access not within mapped region at address 0xFFFFFFFFFFFFE633
    ==26032==    at 0x33AEACB: ??? (in /usr/lib/slack/slack)
    ==26032==    by 0x3D05A77: ??? (in /usr/lib/slack/slack)
    ==26032==    by 0x33A6022: calloc (in /usr/lib/slack/slack)
    ==26032==    by 0xBCF25D0: g_malloc0 (gmem.c:124)
    ==26032==    by 0x91464C8: type_data_make_W (gtype.c:1116)
    ==26032==    by 0x914B854: g_type_register_static (gtype.c:2766)
    ==26032==    by 0x914BAF4: g_type_register_static_simple (gtype.c:2716)
    ==26032==    by 0x7F32F23: gdk_display_manager_get_type (gdkdisplaymanager.c:70)
    ==26032==    by 0x7F32F68: gdk_display_manager_get (gdkdisplaymanager.c:166)
    ==26032==    by 0x7A18953: _gtk_modules_init (gtkmodules.c:533)
    ==26032==    by 0x79FEF27: do_post_parse_initialization (gtkmain.c:789)
    ==26032==    by 0x79FEF27: post_parse_hook (gtkmain.c:824)
    ==26032==    by 0xBCF8FDE: g_option_context_parse (goption.c:2175)
    ==26032==  If you believe this happened as a result of a stack
    ==26032==  overflow in your program's main thread (unlikely but
    ==26032==  possible), you can try to increase the size of the
    ==26032==  main thread stack using the --main-stacksize= flag.
    ==26032==  The main thread stack size used in this run was 8388608.
    ==26032== Invalid read of size 8
    ==26032==    at 0x33AAF1F: ??? (in /usr/lib/slack/slack)
    ==26032==    by 0x33AA2D2: ??? (in /usr/lib/slack/slack)
    ==26032==    by 0x33AA4A6: ??? (in /usr/lib/slack/slack)
    ==26032==    by 0x33B0B33: ??? (in /usr/lib/slack/slack)
    ==26032==    by 0xE46725C: _nl_finddomain_subfreeres (in /lib/x86_64-linux-gnu/libc-2.26.so)
    ==26032==    by 0xE466557: free_mem (in /lib/x86_64-linux-gnu/libc-2.26.so)
    ==26032==    by 0xE4674B2: __libc_freeres (in /lib/x86_64-linux-gnu/libc-2.26.so)
    ==26032==    by 0x5D32671: _vgnU_freeres (in /usr/lib/valgrind/vgpreload_core-amd64-linux.so)
    ==26032==    by 0xAFD5F97: ??? (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
    ==26032==    by 0x33AEB5C: ??? (in /usr/lib/slack/slack)
    ==26032==    by 0x4F: ???
    ==26032==    by 0x4F: ???
    ==26032==  Address 0xffffffffffffe633 is not stack'd, malloc'd or (recently) free'd
    ==26032== 
    ==26032== 
    ==26032== Process terminating with default action of signal 11 (SIGSEGV)
    ==26032==  Access not within mapped region at address 0xFFFFFFFFFFFFE633
    ==26032==    at 0x33AAF1F: ??? (in /usr/lib/slack/slack)
    ==26032==    by 0x33AA2D2: ??? (in /usr/lib/slack/slack)
    ==26032==    by 0x33AA4A6: ??? (in /usr/lib/slack/slack)
    ==26032==    by 0x33B0B33: ??? (in /usr/lib/slack/slack)
    ==26032==    by 0xE46725C: _nl_finddomain_subfreeres (in /lib/x86_64-linux-gnu/libc-2.26.so)
    ==26032==    by 0xE466557: free_mem (in /lib/x86_64-linux-gnu/libc-2.26.so)
    ==26032==    by 0xE4674B2: __libc_freeres (in /lib/x86_64-linux-gnu/libc-2.26.so)
    ==26032==    by 0x5D32671: _vgnU_freeres (in /usr/lib/valgrind/vgpreload_core-amd64-linux.so)
    ==26032==    by 0xAFD5F97: ??? (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
    ==26032==    by 0x33AEB5C: ??? (in /usr/lib/slack/slack)
    ==26032==    by 0x4F: ???
    ==26032==    by 0x4F: ???
    ==26032==  If you believe this happened as a result of a stack
    ==26032==  overflow in your program's main thread (unlikely but
    ==26032==  possible), you can try to increase the size of the
    ==26032==  main thread stack using the --main-stacksize= flag.
    ==26032==  The main thread stack size used in this run was 8388608.
    ==26032== 
    ==26032== HEAP SUMMARY:
    ==26032==     in use at exit: 0 bytes in 0 blocks
    ==26032==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
    ==26032== 
    ==26032== All heap blocks were freed -- no leaks are possible
    ==26032== 
    ==26032== For counts of detected and suppressed errors, rerun with: -v
    ==26032== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
    

Leave a Reply

Your email address will not be published. Required fields are marked *