Skip to content

Example: komodo is not starting

midenok edited this page Nov 21, 2013 · 2 revisions

When we run komodo, we see:

midenok:~$ komodo

(process:10147): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Xlib:  extension "RANDR" missing on display ":0".

(komodo ide:10147): GLib-GObject-WARNING **: Attempt to add property GtkSettings::gtk-button-images after class was initialised

(komodo ide:10147): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::sm-connect after class was initialised

(komodo ide:10147): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::show-crash-dialog after class was initialised

(komodo ide:10147): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::display after class was initialised

(komodo ide:10147): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::default-icon after class was initialised

(komodo:10147): GLib-GObject-WARNING **: Attempt to add property GtkSettings::gtk-entry-select-on-focus after class was initialised

(komodo:10147): GLib-GObject-WARNING **: Attempt to add property GtkSettings::gtk-entry-password-hint-timeout after class was initialised
Segmentation fault

One might think that the cause of Segmentation fault is in GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed. But we should check this first:

midenok:~$ gdb --args `which komodo`
GNU gdb (GDB) 7.5-ubuntu
Copyright (C) 2012 Free Software Foundation, Inc.
...
Reading symbols from /usr/local/bin/komodo...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/local/bin/komodo
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

(process:10512): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Xlib:  extension "RANDR" missing on display ":0".

...
[New Thread 0x7fffe55bf700 (LWP 10524)]
[New Thread 0x7fffe49ff700 (LWP 10525)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe49ff700 (LWP 10525)]
0x000000000041334d in ?? ()
(gdb)

Ok, we got into debugger and now are standing at the point of Segmentation cause. We check stack, and what do we see:

(gdb) bt
#0  0x000000000041334d in ?? ()
#1  0x00007ffff04eb8d9 in PR_SetCurrentThreadName () from /opt/komodo/lib/mozilla/libnspr4.so
#2  0x00007fffec614bab in ?? () from /opt/komodo/lib/mozilla/libxul.so
#3  0x00007fffed4d95ff in ?? () from /opt/komodo/lib/mozilla/libxul.so
#4  0x00007fffed4a89e6 in ?? () from /opt/komodo/lib/mozilla/libxul.so
#5  0x00007fffed4d9f27 in ?? () from /opt/komodo/lib/mozilla/libxul.so
#6  0x00007ffff79bb013 in ?? () from /usr/lib/libnspr4.so
#7  0x00007ffff777ef8e in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#8  0x00007ffff6a86e1d in clone () from /lib/x86_64-linux-gnu/libc.so.6

Nothing suspicious? Well, it is very obvious to me: first it loads /usr/lib/libnspr4.so and then down the stack it loads different binary /opt/komodo/lib/mozilla/libnspr4.so. Of course, it will fail, because second libnspr will try to use resources initialized by first libnspr!

How we can fix it? We need to force komodo to load correct library first time. It is done with LD_PRELOAD env var (look man ld.so):

midenok:~$ export LD_PRELOAD=/opt/komodo/lib/mozilla/libnspr4.so
midenok:~$ komodo

(process:11673): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Xlib:  extension "RANDR" missing on display ":0".
...

Hooray! We have working komodo now, nonetheless a lot of crappy warnings.