libdl bugs
"Markus Wichmann" <[email protected]>
| Newsgroups | gmane.linux.lib.dietlibc |
|---|---|
| Message-ID | <[email protected]> |
Hi all, I don't know, since you don't have a bug tracker, but it could be this problem already got reported. According to the changelog, work on the libdl ceased in 2007. The libdl has a bug causing it to crash with signal 11. The cause is line 803 of _dl_main.c: You are accessing a structure without checking the contents beforehand. Any program linked dynamically against dietlibc has a DT_NEEDED entry for "libc.so". Now my distributor (Debian) ships a linker script called /usr/lib/libc.so. Certainly with the best of intentions, just that the dietlibc's libdl crashes when trying to open it. A simple fix would be to check if the ELF header has got the magic and class right (multilib systems do exist) and ignore the file if it doesn't. I would fix it myself, just that the libdl is a bunch of functions calling each other, I don't know, where to insert the fix. Currently, I put it at line 803 of _dl_main.c, the action being "goto err_out_close", which is the label put where the action of a failing stat() on the file is. Oh, and another thing: The libdl loads files based solely on their file name. DT_NEEDED entries, on the other hand, may contain the libraries' DT_SONAME. Now the glibc features "ldconfig" that symlinks the DT_SONAME of all the libraries to the file name. Basically, dietlibc would need a) something similar, introducing the need for a post library install program run, during which the file system has to be mounted read/write. And the possibility of malfunction due to failure to run said program. or b) to look, upon looking for the library, into each file, to see if the soname equals the needed name. That would mean, for each call to dlopen(), the dynlinker would need to open every ordinary file in the search paths and parse a bit of them. But(!) there would be zero possibility of stale files. Now, since that is a design decision, it is your choice. I don't dare take that on my cap. Basically, it's disk usage against run time. Regards, Markus -- Progress (n.): Process through which USENET evolved from smart people in front of dumb terminals to dumb people in front of smart terminals.