Re: loading bundles stopped working

[Matt Rice]

On Mon, Nov 26, 2018 at 7:18 AM David Chisnall
<gnustep@theravensnest.org> wrote:
>
> On 26/11/2018 15:03, Sebastian Reitenbach wrote:
> >  From the stacktrace, It's the last NSCAssert1 that fires, right after that 
> > line:
> > backend = NSClassFromString (@"GSBackend");
>
> Yup.  That makes me think either:
>
> - The dlopen failed.
> - The dlopen returned success, but didn't call the constructor, so it
> didn't call __objc_exec_class.
> - The library was loaded but some memory was corrupted.

ISTR constructor call order is undefined, and openbsd (has/had) a
called constructors in an order which was
reversed from the order that glibc calls them, so possibly
a) openbsd changed their order,
b) something was added which relies upon the order of calls happening
in the glibc order

could cause the second? i.e. the constructor would eventually be
called, but hasn't been called yet.

> > So before that, there's the other NSCAssert1, [theBundle load], and since
> > this doesn't fire, I think loading it, went OK?
> > But I might well be on the wrong track.
>
> Can you disable the breakpoint on __objc_exec_class until just before
> the [theBundle load] line, then enable it and make sure that it's called
> *after* the dlopen call?  Can you also check in the code that we're
> actually checking the return from dlopen correctly (I'm pretty sure we are).
>
> If all this works, can you check in each __objc_exec_class call and see
> if one of the classes that it loads is called GSBackend?  If so, then it
> looks as if there's still something wrong with the hash table in
> libobjc2.  I think I back-ported all of the fixes to the 1.9 branch, but
> I might have missed one...
>
> David
>
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep