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