tag 21056 notabug thanks On 07/14/2015 03:04 AM, Vinh Nguyen wrote: > Dear Sir/Madam, > I've found a bug with dirname function on Ubuntu 14.04 LTS. The context is: Thanks for the report. However, you have reached the coreutils list (owners of dirname(1) for command line use), but you are complaining about the libc function dirname(3) (for use in C programs); the two are quite distinct. This list is unable to change the libc behavior, so I'm going to close the bug as invalid in the coreutils database. > Dl_info info; > if ( dladdr( ( const void* )function_to_get_address, &info ) == 0 ) > return false; > if ( info.dli_fname == NULL ) > return false; > dirname((char*)info.dli_fname); (1) This is invalid use of dirname(). POSIX says that dirname() may modify its argument, but you MUST NOT modify a const char * string; the fact that you are casting away const should be a warning flag. Furthermore, the POSIX definition of dirname() says that it need not be threadsafe, making it a pain to use in libraries that might be used in a threaded context. Finally, dirname() has fixed semantics that are wrong in code intended to be portable to Windows file names with drive letters. http://pubs.opengroup.org/onlinepubs/9699919799/functions/dirname.html In short, the POSIX dirname() function is worthless; you CANNOT safely use it on untrusted input. The gnulib project has this to say about dirname(), and recommends that you use gnulib's dir_name() instead (which IS safe to use on untrusted input, but which malloc()s the result so you have to adjust your code to free() the result): https://www.gnu.org/software/gnulib/manual/html_node/dirname.html#dirname > > With info.dli_fname contains "./libabc.so". Before (1) is invoked, "info shared" command on gdb 7.1 shows no problem, but after invoking (1), "info shared" shows "." in Shared Object Library column and "No" in Sym column. After that, all "dlopen" functions failed with error "Error while mapping shared library sections" and some libraries throw Segmentation Fault exception. So, I think it is a bug of dirname function. > I hope this information is helpful. I'm looking forward to seeing a fix for this. The fix is not to libc's dirname(), but to your code for invalid usage of dirname(). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org