[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: Gecko/20100430 Fedora/3.0.4-3.fc13 Thunderbird/3.0.4


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 -, 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?


Attachment: errors.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]