#20 dbh race condition

[Napuseno Smith]

This is build 4368.

Doing this repeatedly: Cleaning out all rodent files (caches, configs, what have you) and restarting rodent.

Application may crash with an apparent dbh race: core file is not available at this time. This is the stderr output:

$rm -rf `find ./ -name "rfm"`
$ rodent
dbh_read(): the_user_databytes (139141948) is greater than dbh->head_info->record_length (1024). This is wrong and I stubbornly refuse to read
dbh_read(): the_user_databytes (143536940) is greater than dbh->head_info->record_length (1024). This is wrong and I stubbornly refuse to read
dbh_read(): the_user_databytes (143536940) is greater than dbh->head_info->record_length (1024). This is wrong and I stubbornly refuse to read
dbh_read(): the_user_databytes (139141948) is greater than dbh->head_info->record_length (1024). This is wrong and I stubbornly refuse to read
dbh_read(): the_user_databytes (143536940) is greater than dbh->head_info->record_length (1024). This is wrong and I stubbornly refuse to read
dbh_read(): the_user_databytes (139141948) is greater than dbh->head_info->record_length (1024). This is wrong and I stubbornly refuse to read
dbh_read(): the_user_databytes (143536940) is greater than dbh->head_info->record_length (1024). This is wrong and I stubbornly refuse to read
dbh_read(): the_user_databytes (143536940) is greater than dbh->head_info->record_length (1024). This is wrong and I stubbornly refuse to read
dbh_read(): the_user_databytes (139141948) is greater than dbh->head_info->record_length (1024). This is wrong and I stubbornly refuse to read
dbh_RECORD_SIZE() == 0. This is absurd. Use dbh_set_recordsize ()
mv: no se puede efectuar `stat' sobre «/tmp/s7598.tmp»: No existe el fichero o el directorio

after this, rodent seems to run. But if you close it and then try to reopen rodent, you get a useful core file. Hence the following traceback:

gdb) where
#0 0x002e0422 in __kernel_vsyscall ()
#1 0x00fee651 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0x00ff1a82 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0x0102549d in ?? () from /lib/tls/i686/cmov/libc.so.6
#4 0x0102f591 in ?? () from /lib/tls/i686/cmov/libc.so.6
#5 0x01030de8 in ?? () from /lib/tls/i686/cmov/libc.so.6
#6 0x01033ecd in free () from /lib/tls/i686/cmov/libc.so.6
#7 0x00f08329 in dbh_close (dbh=0x400) at ../../libs/dbh/src/dbh_exported.i:121
#8 0x00aa4be9 in load_hashes_from_cache (module=0x8782240) at ../../libs/rfm/mods/applications-module.i:682
#9 g_module_check_init (module=0x8782240) at ../../libs/rfm/mods/applications-module.c:483
#10 0x0027a8d3 in g_module_open () from /usr/lib/libgmodule-2.0.so.0
#11 0x00f04015 in get_module_info (librarydir=0xf0bc63 "rfm", module_name=0xf0cce4 "applications")
at ../../libs/rfm/libs/primary-modules.c:149
#12 0x00f042a4 in rfm_rational (librarydir=0x6 <Address 0x6 out of bounds>, module_name=0x0, p=0x8737a88,
q=0x8737aa8, function_id=0xf0d14a "mime_type") at ../../libs/rfm/libs/primary-modules.c:240
#13 0x00f05f25 in rfm_resolve_icon_id (en=0x8737a58) at ../../libs/rfm/libs/primary-icons.c:254
#14 0x00f062a0 in rfm_get_composite_icon_id (en=0x8737a58, id=0x0) at ../../libs/rfm/libs/primary-icons.c:264
#15 0x00ad096b in rodent_create_population_t (view_p=0x8732000, en=0x8737a58, element=3, icon_id=0x0,
label=0x873ec80 "uson") at ../../libs/rfm/libs/rodent_population.c:349
#16 0x00ad0ae1 in load_xfdir_icons (data=0x8732000) at ../../libs/rfm/libs/rodent_population.i:832
#17 0x00ad17fb in rodent_full_reload_view (data=0x8732000, target_en=0x873a458)
at ../../libs/rfm/libs/rodent_population.c:871
#18 0x00eb6aa4 in create_desktop () at ../../libs/rfm/deskview/deskview.c:70
#19 0x0804a178 in main (argc=2, argv=0x86b48e0) at ../../src/rfm/fm/rodent.c:383

[Edscott Wilson Garcia]

Duplicate of bugid 3287915.

A better fix is available on build >= 4370. Apparently regen in DBH was going ahead even when dbh temporary file could not be opened. Now it aborts and just does not do the regen.