[Rhythmbox-devel] Trying to debug "Too many open files", hitting "uninitialised value"

[Jan Girlich <vollkorn cryptobitch de>]

Hi,

this is my first post, so I'll introduce myself briefly.

My name is Jan, I'm 31 years old and work as a C/C++ developer in
Hamburg, Germany. At work I do mostly Qt on Windows, but personally I
prefer Linux, although I barely ever code on it.

I came across a bug when importing large (>2000) collections of music
files in the current Rhythmbox-2.99.1-0ubuntu1 on 64 bit:

(gst-switch-srv:1709): GLib-ERROR **: *Creating pipes for GWakeup: Too
many open files*

So I downloaded the source, whipped out valgrind and tried to find out
if all the filedescriptors are closed again by doing:

valgrind --track-fds=yes rhythmbox

Unfortunately I don't get further than shortly after starting Rhythmbox
because of the following crash. As I read it there is an uninitialized
variable and it just goes downhill from there.

Can you help me debugging this further? Like how do I find out which
variable is uninitialised? Remember I'm a Windows dev, just learning to
use the gnu tools.

valgrind output:

==21998== Conditional jump or move depends on uninitialised value(s)
==21998==    at 0x54D65B3: g_type_check_instance (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21998==    by 0x54CC2D3: g_signal_handlers_unblock_matched (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21998==    by 0x4ED0CEE: ignore_selection_changes
(rb-library-browser.c:569)
==21998==    by 0x4ED0D41: query_complete_cb (rb-library-browser.c:593)
==21998==    by 0x54B4187: g_closure_invoke (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21998==    by 0x54C5B1C: ??? (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21998==    by 0x54CD828: g_signal_emit_valist (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21998==    by 0x54CDAE1: g_signal_emit (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21998==    by 0x4EECA4A: idle_process_update (rhythmdb-query-model.c:1216)
==21998==    by 0x4EECBE0: idle_process_update_idle
(rhythmdb-query-model.c:1164)
==21998==    by 0x573D3B5: g_main_context_dispatch (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.3800.1)
==21998==    by 0x573D707: ??? (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.3800.1)
==21998==
==21998== Use of uninitialised value of size 8
==21998==    at 0x54D65B9: g_type_check_instance (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21998==    by 0x54CC2D3: g_signal_handlers_unblock_matched (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21998==    by 0x4ED0CEE: ignore_selection_changes
(rb-library-browser.c:569)
==21998==    by 0x4ED0D41: query_complete_cb (rb-library-browser.c:593)
==21998==    by 0x54B4187: g_closure_invoke (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21998==    by 0x54C5B1C: ??? (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21998==    by 0x54CD828: g_signal_emit_valist (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21998==    by 0x54CDAE1: g_signal_emit (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21998==    by 0x4EECA4A: idle_process_update (rhythmdb-query-model.c:1216)
==21998==    by 0x4EECBE0: idle_process_update_idle
(rhythmdb-query-model.c:1164)
==21998==    by 0x573D3B5: g_main_context_dispatch (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.3800.1)
==21998==    by 0x573D707: ??? (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.3800.1)
==21998==
==21998== Invalid read of size 8
==21998==    at 0x54D65B9: g_type_check_instance (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21998==    by 0x54CC2D3: g_signal_handlers_unblock_matched (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21998==    by 0x4ED0CEE: ignore_selection_changes
(rb-library-browser.c:569)
==21998==    by 0x4ED0D41: query_complete_cb (rb-library-browser.c:593)
==21998==    by 0x54B4187: g_closure_invoke (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21998==    by 0x54C5B1C: ??? (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21998==    by 0x54CD828: g_signal_emit_valist (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21998==    by 0x54CDAE1: g_signal_emit (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21998==    by 0x4EECA4A: idle_process_update (rhythmdb-query-model.c:1216)
==21998==    by 0x4EECBE0: idle_process_update_idle
(rhythmdb-query-model.c:1164)
==21998==    by 0x573D3B5: g_main_context_dispatch (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.3800.1)
==21998==    by 0x573D707: ??? (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.3800.1)
==21998==  Address 0x3 is not stack'd, malloc'd or (recently) free'd
==21998==
==21998==
==21998== Process terminating with default action of signal 11 (SIGSEGV)
==21998==  Access not within mapped region at address 0x3
==21998==    at 0x54D65B9: g_type_check_instance (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21998==    by 0x54CC2D3: g_signal_handlers_unblock_matched (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21998==    by 0x4ED0CEE: ignore_selection_changes
(rb-library-browser.c:569)
==21998==    by 0x4ED0D41: query_complete_cb (rb-library-browser.c:593)
==21998==    by 0x54B4187: g_closure_invoke (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21998==    by 0x54C5B1C: ??? (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21998==    by 0x54CD828: g_signal_emit_valist (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21998==    by 0x54CDAE1: g_signal_emit (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21998==    by 0x4EECA4A: idle_process_update (rhythmdb-query-model.c:1216)
==21998==    by 0x4EECBE0: idle_process_update_idle
(rhythmdb-query-model.c:1164)
==21998==    by 0x573D3B5: g_main_context_dispatch (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.3800.1)
==21998==    by 0x573D707: ??? (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.3800.1)
==21998==  If you believe this happened as a result of a stack
==21998==  overflow in your program's main thread (unlikely but
==21998==  possible), you can try to increase the size of the
==21998==  main thread stack using the --main-stacksize= flag.
==21998==  The main thread stack size used in this run was 8388608.

Cheers
Jan

PS: I'm aware that I can set ulimit to a higher value or import the
files in smaller chunks, but I'd like to get this nasty bug fixed.