Re: loading bundles stopped working

[David Chisnall]

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)?

David