Getting out plugin loading errors

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Getting out plugin loading errors

Ken Hornstein
In the general quest to try to reduce the footprint of our changes to
the MIT Kerberos codebase, we've been trying to move a lot of our
functionality to plugins.  And so far this is going reasonably well, but
there has been one wrinkle: getting the errors from a plugin load failure
in dlopen() is very difficult .

Now I recognize that all of the problems at this point are caused by me,
but it's very hard to figure out what's going wrong via the usual debugging
tools such as system call tracing.  I can see from system call tracing
that the plugin is being opened, but the actual error (usually something
like a missing symbol) isn't in the system call trace.

The actual error message from dlopen() is SORT of captured, but it doesn't
seem like there's a way to get it out.  My reading of the code is that
krb5int_open_plugin() DOES store the error message from dlopen() in the
passed-in errinfo structure, and the callers of krb5int_open_plugin()
seem to pass IN the errinfo pointer from the krb5_context, but at that
point the error is silently swallowed.  Yes, it looks like there are a
few cases where a few specific plugins might return the real error message,
but my reading is that most code calls k5_plugin_load_all() and that
function does not report an error if a plugin fails to load.  And since
that happens pretty deep down in the Kerberos library none of the upper-level
code knows to call the function to retrieve the error message.   You CAN
get the real error message printed out if you compile with -DDEBUG, but
that generates a lot of messages and that's not suitable for production
code.

I get why the dlopen() errors are not logged in the normal course of
things, but it sure would be helpful for plugin development if those
errors could be captured on a temporary basis.  I'd be happy with
any sort of mechanism to do that, including using the existing KRB5_TRACE
mechanism.  If I submitted a patch for that, would it be accepted?

--Ken
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Getting out plugin loading errors

Greg Hudson
On 6/26/20 3:36 PM, Ken Hornstein wrote:
> I get why the dlopen() errors are not logged in the normal course of
> things, but it sure would be helpful for plugin development if those
> errors could be captured on a temporary basis.  I'd be happy with
> any sort of mechanism to do that, including using the existing KRB5_TRACE
> mechanism.

That makes sense.  See:

https://github.com/krb5/krb5/pull/1091
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Getting out plugin loading errors

Ken Hornstein
>On 6/26/20 3:36 PM, Ken Hornstein wrote:
>> I get why the dlopen() errors are not logged in the normal course of
>> things, but it sure would be helpful for plugin development if those
>> errors could be captured on a temporary basis.  I'd be happy with
>> any sort of mechanism to do that, including using the existing KRB5_TRACE
>> mechanism.
>
>That makes sense.  See:
>
>https://github.com/krb5/krb5/pull/1091

I think that change would be perfect for my needs.

--Ken
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev