[Mono-devel-list] [patch]Better error reporting when loading unmanaged libraries

Denis Gervalle dgl at softec.st
Wed May 5 17:51:41 EDT 2004


Here is a proposed enhancement for error reporting when loading external 
unmanaged libraries for p-invoke calls. We have written this patch after 
seaching hard in the dark why a dynamic library next to our mono 
assembly is presumably not found (DllNotFoundException) by mono. Opposed 
to Windows that provide an error message box when LoadLibrary cannot 
properly load a library (usually due to missing dependancies), dlopen do 
not provide this feature (or misfeature since you cannot have try and 
choose an alternative without chocking, tries mono DllImportAttribute 
with a missing library to see successive error message box when it tries 
to load the library using various names (up to 6)).

Under linux, Mono only trigger the laconic DllNotFoundException followed 
by the name of the library as provided in the DllImportAttribute when 
all tries to load the library using various name has failed. It is 
nearly impossible to know why it has fail and what have been tried.

The attached patch (based on the beta release) modify the triggered 
exception to provide a larger error message corresponding to the joined 
error message of all tries done using g_module_open(). Here is an 
example that tries to load sample.so without success due to a missing 
dependency from sample.so to libdependency.so.0

Unhandled Exception: System.DllNotFoundException: libsample.so: cannot 
open shared object file: No such file or directory ==> ./libsample.so: 
cannot open shared object file: No such file or directory ==> 
libdependancy.so.0: cannot open shared object file: No such file or 

 From this detailled exception you can see quickly that mono has tried 
libsample.so and ./libsample.so without success before loading sample.so 
and failing on its dependency. This is not a perfect error report, but 
it is really more intuitive than no message at all.

This patch takes care of mint issues and mono pinvoke-wrapper issues. 
For the latter, each exception messages are allocated permanently on the 
heap since the exception is triggered by the wrapper code for each call 
to a function from the missing library (and not during the loading 
phase). This may be a anoying issue if a program tries lots of missing 
libraries in a single run (catching exceptions), but there is absolutly 
no alternative and this is more a theoric issue than a pratical one (Do 
you often declare lots of static dependencies you do not really need ?). 
However, this may advocate for a conditional usage of this new feature, 
but how that could be done is over my current knowledge of mono internals.
The patch also fix some unrelated compilation warnings in icall.c.

I know that we arrive late for the 1.0 release. Anyway, remember that 
without this detailed exception, it will be a pain to track down these 
library issues in large project using a mix of managed and unmanaged 

Hope this helps,

Denis Gervalle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: loadmodule.unified.diff.patch
Type: text/x-patch
Size: 3205 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040505/f2189817/attachment.bin 

More information about the Mono-devel-list mailing list