Re: loading bundles stopped working

[Sebastian Reitenbach]

Am Montag, November 26, 2018 12:22 CET, David Chisnall 
<gnustep=@theravensnest.org> schrieb:

> On 26/11/2018 08:47, Sebastian Reitenbach wrote:
> > Program received signal SIGFPE, Arithmetic exception.
> > 0x00000527770d024c in _dl_find_symbol_obj (obj=0x52722e05c00, 
> > sl=0x7f7fffff5108) at /usr/src/libexec/ld.so/resolve.c:584
> > 584             for (si = obj->buckets[sl->sl_elf_hash % obj->nbuckets];
> > (gdb) bt
> > #0  0x00000527770d024c in _dl_find_symbol_obj (obj=0x52722e05c00, 
> > sl=0x7f7fffff5108) at /usr/src/libexec/ld.so/resolve.c:584
> > #1  0x00000527770d0068 in _dl_find_symbol (name=0x526ae984ea5 "getpid", 
> > this=0x7f7fffff51a8, flags=48, ref_sym=0x526ae9194c8, req_obj=<optimized 
> > out>, pobj=0x7f7fffff51a0)
> >      at /usr/src/libexec/ld.so/resolve.c:663
> > #2  0x00000527770cef1a in _dl_bind (object=0x526d8585800, index=<optimized 
> > out>) at /usr/src/libexec/ld.so/amd64/rtld_machine.c:357
> > #3  0x00000527770d0fed in _dl_bind_start () at 
> > /usr/src/libexec/ld.so/amd64/ldasm.S:108
>
> The top bit of this backtrace makes me slightly suspicious.  It looks as
> if we're seeing memory corruption.  I can think of two plausible causes
> of this:
>
> 1. Something in GNUstep is corrupting some heap state and this happens
> to be hitting something in OpenBSD's run-time linker.  Given OpenBSD's
> aggressive ASLR, this doesn't seem very likely to happen deterministically.
> 2. lld is generating something in the object file that is not supported
> by OpenBSD's run-time linker.  This seems more likely, because
> Objective-C tends to use a few bits of ELF that aren't as widely used by
> C/C++ and may not be well-tested code paths in OpenBSD's linker.
>
> Did the dlopen of the back end definitely succeed?  Did it call
> __objc_exec_class correctly (or __objc_load if you're using the v2 ABI)?

I did hit the
Breakpoint 1, __objc_exec_class (module=0x8f61a4aa800) at 
/home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/libobjc2-1.9.0/loader.c:47

functions I think maybe a hundred of times, so, not sure which of these really 
is the culprit, since there are soo many hits,
I haven't yet managed to get to the last one and step through it.

However, from where the problem come from is  in -guis NSApplication.m:



BOOL
initialize_gnustep_backend(void)
{
  static int first = 1;

  if (first)
    {
      Class backend;

      /*
      Remember which thread we are running in. This thread will be the
      -gui thread, ie. the only thread that may do any rendering. With
      the exception of a few methods explicitly marked as thread-safe,
      other threads should not call any methods in -gui.
      */
      GSAppKitThread = [NSThread currentThread];

      first = 0;
#ifdef BACKEND_BUNDLE
      {
        NSBundle *theBundle;
        NSString *path, *bundleName;
        NSUserDefaults  *defs = [NSUserDefaults standardUserDefaults];

        /* What backend ? */
        bundleName = [defs stringForKey: @"GSBackend"];
        path = gnustep_backend_framework (bundleName);
        if (path == nil)
          {
            NSDebugLLog(@"BackendBundle", @"Did not find backend framework.");
            path = gnustep_backend_bundle (bundleName);
          }

        /* FIXME/TODO - update localized error messages.  */

        /* Backend found ? */
        if (bundleName == nil)
          bundleName = @"back";
        NSCAssert1(path != nil, _(@"Unable to find backend %@"), bundleName);
        NSDebugLog(@"Loading Backend from %@", path);
        NSDebugFLLog(@"BackendBundle", @"Loading Backend from %@", path);

        /* Create a bundle object.  (Should normally succeed).  */
        theBundle = [NSBundle bundleWithPath: path];
        NSCAssert1(theBundle != nil,
                   _(@"Can't create NSBundle object for backend at path %@"),
                   path);

        /* Now load the object file from the bundle.  */
        NSCAssert1 ([theBundle load],
                    _(@"Can't load object file from backend at path %@"),
                    path);

        /* Now get the GSBackend class, which should have just been loaded
         * from the bundle.  */
        backend = NSClassFromString (@"GSBackend");
        NSCAssert1 (backend != Nil,
          _(@"Backend at path %@ doesn't contain the GSBackend class"), path);
        [backend initializeBackend];
      }

#else
      /* GSBackend will be in a separate library linked in with the app.
       This would be cleaner with ...classNamed: @"GSBackend", but that
       doesn't work in some cases (Mac OS X for instance).  */
      [GSBackend initializeBackend];
#endif
    }
  return YES;
}

>From the stacktrace, It's the last NSCAssert1 that fires, right after that 
>line:
backend = NSClassFromString (@"GSBackend");

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.

Sebastian


>
> David