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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.