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
_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
