[Bug dynamic-link/14989] New: dlerror() returns garbage

[Bug dynamic-link/14989] New: dlerror() returns garbage

[Arfrever.FTA at GMail dot Com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14989

             Bug #: 14989
           Summary: dlerror() returns garbage
           Product: glibc
           Version: 2.16
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dynamic-link
        AssignedTo: unassigned@sourceware.org
        ReportedBy: Arfrever.FTA@GMail.Com
    Classification: Unclassified


$ gcc -xc - -fPIC -shared -o libtest.so <<< ""
$ cat dlerror_test.c
#include <dlfcn.h>
#include <stdio.h>

int main()
{
  void* handle = dlopen("libtest.so", RTLD_NOW);
  dlclose(handle);
  dlclose(handle);
  printf("dlerror(): '%s'\n", dlerror());
}
$ gcc -o dlerror_test dlerror_test.c -ldl
$ LD_LIBRARY_PATH="." ./dlerror_test
dlerror(): '�Ue: shared object not open'
$ LD_LIBRARY_PATH="." ./dlerror_test
dlerror(): '��: shared object not open'
$ LD_LIBRARY_PATH="." ./dlerror_test
dlerror(): '�u�: shared object not open'
$ LD_LIBRARY_PATH="." ./dlerror_test
dlerror(): '��5: shared object not open'
$ LD_LIBRARY_PATH="." ./dlerror_test
dlerror(): '�5�: shared object not open'
$ LD_LIBRARY_PATH="." ./dlerror_test
dlerror(): '�*: shared object not open'
$ LD_LIBRARY_PATH="." ./dlerror_test
dlerror(): '�%�: shared object not open'
$ LD_LIBRARY_PATH="." ./dlerror_test
dlerror(): '�e=: shared object not open'

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug dynamic-link/14989] dlerror() returns garbage

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=14989

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugdal at aerifal dot cx
         Resolution|                            |INVALID

--- Comment #1 from Rich Felker <bugdal at aerifal dot cx> 2012-12-31 00:20:31 UTC ---
You invoked undefined behavior by a double-free type error. After the first
dlclose, handle is not valid, and you therefore cannot pass it to dlclose again
or do anything else with it.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug dynamic-link/14989] dlerror() returns garbage

[Arfrever.FTA at GMail dot Com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14989

Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail dot Com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |
     Ever Confirmed|1                           |0

--- Comment #2 from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail dot Com> 2012-12-31 09:18:23 UTC ---
Failure of second dlclose() is expected. This bug is about wrong library name
in message returned by dlerror(). dlerror() returns correct name of library in
case of libc.so.6, but not in case of majority of other libraries.

$ cat dlerror_test.c
#include <dlfcn.h>
#include <stdio.h>
#include <string.h>

int main(int argc, char** argv)
{
  int i;
  for (i = 1; i < argc; i++)
  {
    char buffer[1024];
    snprintf(buffer, 1024, "%s:", argv[i]);
    printf("%-20s", buffer);
    void* handle = dlopen(argv[i], RTLD_NOW);
    if (handle)
    {
      dlclose(handle);
      dlclose(handle);
      printf("dlerror() after double dlclose() : ");
    }
    else
    {
      printf("dlerror() after dlopen()  : ");
    }
    printf("'%s'\n", dlerror());
  }
}
$ gcc -o dlerror_test dlerror_test.c -ldl
$ ./dlerror_test libncurses.so.5 libreadline.so.6 libz.so.1 libc.so.6
libncurses.so.5:    dlerror() after double dlclose() : '0%>: shared object not
open'
libreadline.so.6:   dlerror() after double dlclose() : '*>: shared object not
open'
libz.so.1:          dlerror() after double dlclose() : 'P%>: shared object not
open'
libc.so.6:          dlerror() after double dlclose() : '/lib64/libc.so.6:
shared object not open'

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug dynamic-link/14989] dlerror() returns garbage

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=14989

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #3 from Rich Felker <bugdal at aerifal dot cx> 2012-12-31 15:10:36 UTC ---
No, failure is not expected. Undefined behavior is expected. Undefined behavior
is completely different from failure. If your program causes undefined
behavior, all bets are off. There is absolutely no requirement on any output of
the program, not even output that was logically generated before the undefined
behavior was invoked. Programs which invoke undefined behavior are completely
invalid and any bug report referring to the behavior of a program that has
invoked undefined behavior is invalid.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug dynamic-link/14989] dlerror() returns garbage

[Arfrever.FTA at GMail dot Com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14989

Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail dot Com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |

--- Comment #4 from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail dot Com> 2013-01-01 10:11:31 UTC ---
Behavior of dlclose() is defined in POSIX:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/dlclose.html

"RETURN VALUE

If the referenced object was successfully closed, dlclose() shall return 0. If
the object could not be closed, or if handle does not refer to an open object,
dlclose() shall return a non-zero value. More detailed diagnostic information
shall be available through dlerror()."

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug dynamic-link/14989] dlerror() returns garbage

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=14989

--- Comment #5 from Rich Felker <bugdal at aerifal dot cx> 2013-01-01 21:27:01 UTC ---
I've referred the issue to the Austin Group:

http://austingroupbugs.net/view.php?id=639

Calling dlclose on an invalid handle is conceptually just as invalid (i.e. just
as much a programming error) as calling free on an invalid pointer, but indeed
the current text of the standard seems to specify a behavior for that case
which imposes a heavy implementation burden; there's no way to satisfy the
requirement without walking the entire list of loaded libraries to check
whether handle matches any of them before using it, and I'm not aware of any
implementations which do this.

Apologies for responding prematurely without researching the issue.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug dynamic-link/14989] dlerror() returns garbage

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=14989

--- Comment #6 from Rich Felker <bugdal at aerifal dot cx> 2013-01-10 18:56:36 UTC ---
Austin Group Issue #639 was closed with a resolution that the implementation is
required, as currently written, to detect the use of invalid handles.
Therefore, glibc is presently non-conforming. All functions which take DSO
handles should be updated to walk the loaded DSO list and check that the
argument matches the handle of a valid loaded DSO before making any other use
of the argument.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug dynamic-link/14989] dlerror() returns garbage

[neleai at seznam dot cz]

https://sourceware.org/bugzilla/show_bug.cgi?id=14989

Ondrej Bilka <neleai at seznam dot cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |neleai at seznam dot cz
         Resolution|---                         |INVALID

--- Comment #7 from Ondrej Bilka <neleai at seznam dot cz> ---
This does not change that libraries can be closed unlimited number of times and
requiring to keep all names would be equivalent to resource leak. There is
currently no quarantee that detailed error will contain accurate name. Keeping
a limited history would be a enchancement.

As for compilance a dlsym already does a linear search, see elf/dl_open.c
function _dl_find_dso_for_object.

A requirement of returning NULL complicates this, it implies that dlsym/dlclose
need to be thread-safe as there would be race. Also on 32bit systems this
condition is impossible to fulfill after 1+1<<32 dlopens/dlcloses,

Barring locking a implementation is matter of choosing correct data structure
which is in our case perfect hash table. As can choose keys arbitrarily we
could just pick first free position and increment last key.

dso **__dso_ary;
int __logsize;
dlsym(long x){
  long hash = (x<<logsize)>>logsize;
  dso *d = __dso_ary[hash];
  if (d->key != x)
    return NULL;
}

dlopen(...){
  long hash=free_pos();
  dso *d = __dso_ary[hash];
  d->key = hash + (d->last_key + 1) % (1<<logsize);
  long x = d->key;
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/14989] dlerror() returns garbage

[bugdal at aerifal dot cx]

https://sourceware.org/bugzilla/show_bug.cgi?id=14989

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
   Last reconfirmed|                            |2013-10-11
         Resolution|INVALID                     |---
     Ever confirmed|0                           |1

--- Comment #8 from Rich Felker <bugdal at aerifal dot cx> ---
I believe it's actually possible for the current code to crash rather than
returning a junk string, so this bug should not be closed so quickly. Per the
interpretation I cited above (which I agree is unfortunate) an implementation
is not permitted to crash if an invalid DSO handle is passed. It must diagnose
the error. I would support an effort to have this requirement removed in the
next issue of POSIX.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/14989] dlerror() returns garbage

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14989

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/14989] dlerror() returns garbage

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14989

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.