[BRLTTY] dlsym/dlerror (was Re: Clumping all the braille driver modules into one big app?)

[Willie Walker]

I'm not sure I understand the issue.  Here's the docs from Solaris:

DESCRIPTION
      The  dlerror()  function returns a null-terminated character
      string that describes the last error  that  occurred  during
      dynamic  linking processing. The returned string contains no
      trailing newline. If no dynamic linking errors have occurred
      since  the  last  invocation of dlerror(), dlerror() returns
      NULL. Thus, invoking  dlerror() a second  time,  immediately
      following   a   prior  invocation,  results  in  NULL  being
      returned.

Here's what I can see for Linux:

dlerror
The function dlerror() returns a human readable string describing the 
most recent error that occurred from dlopen(), dlsym() or dlclose() 
since the last call to dlerror(). It returns NULL if no errors have 
occurred since initialization or since it was last called.

So, what I'm suggesting is merely adding a call to dlerror prior to the 
call to dlsym in the code in question.  This would clear any prior error 
state and thus make sure that the existing call to dlerror would obtain 
results (if any) for the existing call to dlsym.  The line in question 
would be something like the line marked with "==>" below:

int
findSharedSymbol (void *object, const char *symbol, void *pointerAddress) {
#ifdef HAVE_DLOPEN
   void **address = pointerAddress;
==> dlerror(); /* Clear any prior error state */ <==
   *address = dlsym(object, symbol);

   {
     const char *error = dlerror();
     if (!error) return 1;
     LogPrint(LOG_ERR, "%s", error);
   }
#endif /* HAVE_DLOPEN */
   return 0;
}

The _ex_unwind thing is a bit of a mystery to me, but it has something 
to do with C/C++ linkage, I believe.  The code checks for the existence 
of this symbol and moves on if it doesn't exist.  But, it seems to fail 
to clear the error state.

However, the fix already provided works and if you want to go with it, 
I'm happy with that.  :-)

Thanks!

Will

Dave Mielke wrote:
> [quoted lines by Willie Walker on 2008/08/29 at 08:17 -0400]
> 
>> Given the below, this might actually turn into a one line 
>> fix to call dlerror() just before calling dlsym().  That should clear 
>> any existing error conditions and your existing code would continue to 
>> work, I think.
> 
> Mightn't that potentially lead to exactly the same problem, i.e. dlerror() 
> being caleld when there's no pending error? Since we do call dlerror() whenever 
> there is an error, I'd expect that to be the case. 
> 
> Can one of your people give me a more detailed description as to what the 
> precise problem is? With a name like _ex_unwind() being involved, I'd expect it 
> to have to do with the stack frame linkage being different at the time 
> dlerror() is called from the time when the error actually occurred. If so, 
> there's no easy solution.
>