Re: loading bundles stopped working

[Matt Rice]

On Mon, Nov 26, 2018 at 7:18 AM David Chisnall
 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

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: loading bundles stopped working

[David Chisnall]

On 26/11/2018 20:40, Sebastian Reitenbach wrote:

  I think I finally found where the dlopen() is called, in gnustep base
dynamic-load.h (which is generated while building it, took me a while
to find that ;)

 From what I can see, things look good as it successfully dlopens
the gnustep-back backend file, but then it never calls __objc_exec_class??


I can't tell for sure from your debugging log, but it looks as if you 
don't have a breakpoint set on __objc_exec_class when you step over the 
dlopen call.  You won't be able to step into dlopen (unless you want to 
recompile rtld with debug info, but I wouldn't recommend that), so you 
need to make sure that you set the breakpoint before you let the process 
call dlopen.  You can then step into the __objc_exec_class calls and see 
if it's actually loading things correctly.


David

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep