[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RFC] [PATCH] libltdl error reporting
From: |
Peter O'Gorman |
Subject: |
[RFC] [PATCH] libltdl error reporting |
Date: |
Thu, 10 Jun 2010 00:33:24 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-3.fc13 Thunderbird/3.0.4 |
Hi,
As I am sure many are aware, libltdl's error reporting is pretty dumb,
lt_dlerror() regularly reports things like "file not found" where the
actual problem might be something completely different, and a reasonable
error string may be readily available from dlerror().
When I looked at the manual, and read the description for lt_dlerror() I
saw "Return a human readable string describing the most recent error
that occurred from any of libltdl's functions. Return NULL if no errors
have occurred since initialization or since it was last called." and I
thought "Well, that's stupid - that's not what dlerror() does". So, I
went to see what POSIX says - it's also wrong -
http://www.opengroup.org/onlinepubs/9699919799/functions/dlerror.html, I
will file a bug with them later.
At least glibc and Mac OS X reset the dlerror() string to NULL every
time a dl*() api is called (I will check what other systems do in the
next few days). This is so programmers can do:
.....
dlsym(handle, "foo");
if ((err = dlerror()) != NULL) printf(stderr,"dlsym error: %s\n",err);
...
without dlerror() returning some other error that occurred long before
the call to dlsym().
Unfortunately, it looks like libltdl attempts to save error state across
calls to lt_*() functions, and generally does not do it well.
This patch resets the error every time a public ltdl function is called,
and when setting an error tests if it is already set and doesn't
overwrite it if it is. The fist error "wins".
The patch is fairly simple, and undoubtedly still imperfect, but test
results are good, one test required a small patch to stop segfaulting,
another should have unexpectedly passed, but doesn't, I think it is
another error in the test, but haven't looked too closely yet.
If something like this does get in, I'd prefer to not change the libltld
soname, I don't believe better error reporting will cause client
applications to break. I could be wrong, of course :)
Patch attached (or course, a final patch will have to change the manual
as well) - thoughts?
Peter
errors.patch
Description: Text Data
- [RFC] [PATCH] libltdl error reporting,
Peter O'Gorman <=
Re: [RFC] [PATCH] libltdl error reporting, Bob Friesenhahn, 2010/06/10
Re: [RFC] [PATCH] libltdl error reporting, Peter O'Gorman, 2010/06/14