#19 crash on clean startup

[Napuseno Smith]

On rodent buid 4359, On a clean system i get after startup:

$ rodent
fcntl(F_SETLKW)(/home/edscott/.cache/rfm/modules/applications.sfx.cache64.dbh): Se ha evitado un bloqueo de recursos
mv: no se puede efectuar `stat' sobre «/tmp/s4360.tmp»: No existe el fichero o el directorio

but rodent seems to start ok. But almost after initial activity I get a core dump when I try to get the properties dialog for an item.

Segmentation fault.
#0 0x004c755a in g_object_ref () from /usr/lib/libgobject-2.0.so.0
(gdb) where
#0 0x004c755a in g_object_ref () from /usr/lib/libgobject-2.0.so.0
#1 0x001279a8 in rodent_preview_if_loaded (population_p=0x8284fb8)
at ../../libs/rfm/libs/rodent_mouse.c:1142
#2 rodent_preview (population_p=0x8284fb8)
at ../../libs/rfm/libs/rodent_mouse.c:1174
#3 0x05857575 in dlg_prop (properties_p=0x8200600)
at ../../libs/rfm/mods/properties-module.i:1062
#4 0x05857970 in do_prop (p=0x812f554)
at ../../libs/rfm/mods/properties-module.c:150
#5 0x003582d2 in rfm_rational (librarydir=0x132f6b "rfm",
module_name=0x133780 "properties", p=0x812f554, q=0x81e5480,
function_id=0x132f7d "do_prop")
at ../../libs/rfm/libs/primary-modules.c:250
#6 0x00118dc2 in rodent_on_prop_activate (menuitem=0x81fe360,
user_data=0x812f554) at ../../libs/rfm/libs/rodent_popup.i:1295
#7 0x004d2dcc in g_cclosure_marshal_VOID__VOID ()
from /usr/lib/libgobject-2.0.so.0
#8 0x004c5252 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#9 0x004d999d in ?? () from /usr/lib/libgobject-2.0.so.0
#10 0x004dadb4 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#11 0x004db256 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#12 0x00ceb3e5 in gtk_widget_activate () from /usr/lib/libgtk-x11-2.0.so.0
#13 0x00bc99a0 in gtk_menu_shell_activate_item ()
#14 0x00bcb31f in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#15 0x00bc0c64 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#16 0x00bba424 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#17 0x004c38b9 in ?? () from /usr/lib/libgobject-2.0.so.0
#18 0x004c5252 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#19 0x004d95e6 in ?? () from /usr/lib/libgobject-2.0.so.0
#20 0x004dac33 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#21 0x004db256 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#22 0x00ce7636 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#23 0x00bb2a5d in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0
#24 0x00bb3e07 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#25 0x00f1339a in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#26 0x007075e5 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#27 0x0070b2d8 in ?? () from /lib/libglib-2.0.so.0
#28 0x0070b817 in g_main_loop_run () from /lib/libglib-2.0.so.0
#29 0x00bb43c9 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#30 0x0804a19f in main (argc=2, argv=0x80898e0)

[Edscott Wilson Garcia]

Core dump situation is now fixed for build >=4365.

The bug is not yet closed because the warning described before the crash is unrelated to the fixed core dump problem.

Thank you for the helpful gdb traceback.

[Edscott Wilson Garcia]

The initial warning condition is fixed and should not occur again. Seems that two separate dbh threads asked for a temporary file at the same time, and the second thread could not access the file because of the file lock. The condition is now fixed in dbh, as a check is made for file existance to garantee that temporary files do not exist when the path is requested for the first time.

This closes the bug. Thank you for feedback.