From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7 Description of problem: When a module named as first parameter to dlopen() cannot be loaded, then _dl_map_object_from_fd in elf/dl-load.c calls _dl_debug_state with a struct link_map for the failed module still on the _r_debug.r_map chain. This can confuse a debugger that is watching _dl_debug_state, because there is no indication in the public part of struct link_map that the module was not loaded. The values in the public part of struct link_map can appear to be "normal", but they are bad. Version-Release number of selected component (if applicable): glibc-2.3.90-30 How reproducible: Always Steps to Reproduce: 1. Put a breakpoint on _dl_debug_state, then run internal testcase elf/nodlopen, which tries to dlopen("nodlopenmod.so"). This must fail because the module is marked DF_1_NOOPEN to inhibit dynamic loading; only loading to satisfy static dependency of a main program is allowed. 2. Observe the _r_debug.r_map chain when _dl_map_object_from_fd calls _dl_debug_state just after failing to load dlopenmod.so. 3. Actual Results: The _r_debug.r_map chain has "nodlopen" [the main program] "" [the vDSO] "libdl.so.2" "libc.so.6" "ld-linux.so.2" "nodlopenmod.so" [the module that was not loaded] Expected Results: The failed module should be removed from the chain before calling _dl_debug_state. Additional info: It appears as if all of the "goto call_lose" instances should remove the failing link_map from the chain before calling _dl_debug_state.
These bugs are being closed since a large number of updates have been released after the FC5 test1 and test2 releases. Kindly update your system by running yum update as root user or try out the third and final test version of FC5 being released in a short while and verify if the bugs are still present on the system .Reopen or file new bug reports as appropriate after confirming the presence of this issue. Thanks