[Mono-devel-list] [patch]Better error reporting when loading unmanaged libraries
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,
-------------- next part --------------
A non-text attachment was scrubbed...
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