Re: loading bundles stopped working
Hi Sebastian, On 7 Oct 2019, at 12:31, Sebastian Reitenbach wrote: So instead of linking everything, esp. -base with lld, I should only link -back and SOPE with bfd, and all the rest will hopefully work linked with lld. Would that be the recommneded way to go ahead, or is there meanwhile some other better way I'm not aware of yet? the way to go is to use ld.gold - at least that’s what I was told and what works well under Debian GNU/Linux (with the exception of Gworkspace as mentioned in the other thread). Patrick and I have put together some build scripts that use ld.gold for Ubuntu and Debian: https://github.com/plaurent/gnustep-build My scripts derive from a howto from Andreas Fink that mentions FreeBSD as well: http://wiki.gnustep.org/index.php/Building_GNUstep_under_Debian_FreeBSD Good luck Johannes ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: loading bundles stopped working
Hi, I've to revive this old thread. Am Sonntag, Dezember 30, 2018 14:51 CET, schrieb David Chisnall : > On 25/11/2018 18:30, Sebastian Reitenbach wrote: > > Hi, > > > > since a good months ago, on OpenBSD -current amd64, bundle loading stopped > > working. I'm not sure what caused it, at least nothing with regard to objc > > and gnustep, since I haven't touched the packages since then. > > I have now managed to reproduce this on FreeBSD. It appears that lld > does not like GNUstep-back (or SOPE, for that matter) and generates a > subtly broken library. Using gold to link -back and lld for everything > else appears to work. > > I now have (locally, not yet committed upstream) the FreeBSD packages > using the v2 ABI and GUI apps running. I found a couple of small clang > bugs, both of which are now fixed upstream (one prevents -base configure > from running, but doesn't prevent anything real from working - it is > only a problem if you create a program or library that doesn't contain > any Objective-C classes, but does use Objective-C). I've also merged > the changes for the new constant string representations into -base. > > I'm still debugging a few things. Cenon crashes on startup (before > entering main, could be another LLD incompatibility). Gorm is quite > broken with the new ABI because it adds a bunch of categories that > expose @private fields from classes in AppKit: this is not allowed now > that @private is enforced by the linker (I don't believe it works on > Apple platforms either, for the same reason - the ivar offset variables > are only publicly exported for things that are part of the public > interface). It's still possible to access ivars via reflection, but you > then have an opportunity to check that the Ivar that the runtime returns > is not NULL. I'll try to push some fixes for these things in the next > few days. > I'm on OpenBSD -current amd64, which meanwhile comes with clang version 8.0.1 (tags/RELEASE_801/final) (based on LLVM 8.0.1). Also, in the meantime, I updated to libobjc2-2.0, and enforce using new ABI with passing in -fobjc-runtime=gnustep-2.0 to all linking, as well as when building libobjc2, I set OLDABI_COMPAT=Off to be sure nothing accidently ignores the fobjc-runtime properly. Other GNUstep packages are latest releases. However, when I drop the -fuse-ld=bfd, in order to lld, I still run into the floating point exceptions I saw a year ago. I link everything GNUstep with bfd instead of lld. So, now that I link -base with lld, it seems to prevent an update of icu4c. Not sure what the breakage is, but some fellow packager pointed that out to me. Should these clang fixes you mentioned be in 8.0.1 ? When I look here [1] to the changelog from 03 Feb 2019, as you explained above, your solution to it is just building -back and SOPE with the old linker instead of building everything. So instead of linking everything, esp. -base with lld, I should only link -back and SOPE with bfd, and all the rest will hopefully work linked with lld. Would that be the recommneded way to go ahead, or is there meanwhile some other better way I'm not aware of yet? cheers, Sebastian [1] https://www.freshports.org/lang/gnustep-base/ ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: loading bundles stopped working
On 25/11/2018 18:30, Sebastian Reitenbach wrote: Hi, since a good months ago, on OpenBSD -current amd64, bundle loading stopped working. I'm not sure what caused it, at least nothing with regard to objc and gnustep, since I haven't touched the packages since then. I have now managed to reproduce this on FreeBSD. It appears that lld does not like GNUstep-back (or SOPE, for that matter) and generates a subtly broken library. Using gold to link -back and lld for everything else appears to work. I now have (locally, not yet committed upstream) the FreeBSD packages using the v2 ABI and GUI apps running. I found a couple of small clang bugs, both of which are now fixed upstream (one prevents -base configure from running, but doesn't prevent anything real from working - it is only a problem if you create a program or library that doesn't contain any Objective-C classes, but does use Objective-C). I've also merged the changes for the new constant string representations into -base. I'm still debugging a few things. Cenon crashes on startup (before entering main, could be another LLD incompatibility). Gorm is quite broken with the new ABI because it adds a bunch of categories that expose @private fields from classes in AppKit: this is not allowed now that @private is enforced by the linker (I don't believe it works on Apple platforms either, for the same reason - the ivar offset variables are only publicly exported for things that are part of the public interface). It's still possible to access ivars via reflection, but you then have an opportunity to check that the Ivar that the runtime returns is not NULL. I'll try to push some fixes for these things in the next few days. David ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: loading bundles stopped working
Hi,
Am Mittwoch, November 28, 2018 14:03 CET, David Chisnall
schrieb:
> On 28/11/2018 12:55, Sebastian Reitenbach wrote:
> > since both work, don't know how helpful the objdump will be.
>
> Not very. Can you try making lib.c into a lib.m that implements a class
> with a +load method (and add -lobjc to the compile command for loadlib.c)?
>
> David
so I used this as the lib.m:
#include
#import
@interface testlib: NSObject
{
}
@end
@implementation testlib
+ (void) load {
puts("Library loaded");
}
@end
And this command to compile it:
clang -shared -fPIC -Wl,-E -Wl,-R/usr/local/lib -L/usr/local/lib
-Wl,-R/usr/local/lib -L/usr/local/lib -pthread -fexceptions -o lib.so
-L/usr/local/lib -lstdc++ -lm -lgnustep-base-lpthread -lobjc2
-fobjc-nonfragile-abi -lm -lc++abi
and your loadlib.c:
#include
#include
int main(void)
{
puts("Program started");
dlopen("./lib.so", RTLD_LAZY | RTLD_GLOBAL);
return 0;
}
and then clang loadlib.c
then it only prints:
Program started
in both cases.
I guess I miss something, since its not working for both cases.
When not using the -fuse-ld flag, I also had gnustep-base compiled without that
flag, using lld.
When compiling lib.m with -fuse-ld=bfd, I had rebuilt gnustep-base compiled
with that flag as well.
Sebastian
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: loading bundles stopped working
On 28/11/2018 12:55, Sebastian Reitenbach wrote: since both work, don't know how helpful the objdump will be. Not very. Can you try making lib.c into a lib.m that implements a class with a +load method (and add -lobjc to the compile command for loadlib.c)? David ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: loading bundles stopped working
Am Mittwoch, November 28, 2018 13:42 CET, David Chisnall
schrieb:
> On 28/11/2018 11:35, Sebastian Reitenbach wrote:
> > (gdb) info break
> > Num Type Disp Enb AddressWhat
> > 1 breakpoint keep y 0x093f1dcad9a2 in
> > initialize_gnustep_backend at NSApplication.m:309
> > breakpoint already hit 1 time
> > 2 breakpoint keep y 0x093ec291a170 in -[NSBundle load] at
> > NSBundle.m:1989
> > 3 breakpoint keep y 0x093ec2b2a750 in __objc_dynamic_link
> > at ././dynamic-load.h:63
> > 5 breakpoint keep y 0x093e64843ae0 in __objc_exec_class at
> > /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/libobjc2-1.9.0/loader.c:46
> > (gdb) c
> > Continuing.
> >
> > Breakpoint 2, -[NSBundle load] (self=0x93e9baac588, _cmd=0x93e69deea88) at
> > NSBundle.m:1989
> > 1989- (BOOL) load
> > (gdb)
> > Continuing.
> >
> > Breakpoint 3, __objc_dynamic_link (module=0x93f0c45f248 "8\212\273\302>\t",
> > mode=2366, debug_file=0x93f3d9fa8e0 <__sF+304> "") at ././dynamic-load.h:64
> > warning: Source file is more recent than executable.
> > 64 {
> > (gdb)
> > Continuing.
> >
> > Program received signal SIGFPE, Arithmetic exception.
> > 0x093e70b4124c in _dl_find_symbol_obj (obj=0x93ecb3bbc00,
> > sl=0x7f7d33f8) at /usr/src/libexec/ld.so/resolve.c:584
> > 584 for (si = obj->buckets[sl->sl_elf_hash % obj->nbuckets];
> >
> > So I stopped at NSApplication.m:309, and then added the breakpoints in
> > dynamic-load.h and in libobjc loader.c where the __objc_exec_class resides,
> > and then continued to execute, but it doesn't hit the breakpoint 5 before
> > throwing the FPE.
>
>
> Okay, it looks as if libraries that are linked with lld are not getting
> their global constructors called on OpenBSD. Can you try this test?
>
> =$ cat lib.c
> #include
>
> __attribute__((constructor))
> void load(void)
> {
> puts("Library loaded");
> }
> [theraven@FBSDVM /tmp]$ cat loadlib.c
> #include
> #include
>
> int main(void)
> {
> puts("Program started");
> dlopen("./lib.so", RTLD_LAZY | RTLD_GLOBAL);
> return 0;
> }
> $ clang60 lib.c -shared -o lib.so -fPIC -fuse-ld=lld
> $ clang loadlib.c
> $ ./a.out
> Program started
> Library loaded
>
>
> If it prints both of the lines above, the library was correctly loaded
> and the global constructors were run. If it works with -fuse-ld=lld but
> not -fuse-ld=bfd, then that tells us that this really is the problem.
> Objdump of the bfd and lld versions of lib.so should help us identify
> the differences.
>
> David
sebastia@communicator:~> vi lib.c
sebastia@communicator:~> vi loadlib.c
sebastia@communicator:~> clang lib.c -shared -o lib.so -fPIC -fuse-ld=lld
sebastia@communicator:~> clang loadlib.c
sebastia@communicator:~> ./a.out
Program started
Library loaded
sebastia@communicator:~> rm lib.so a.out
sebastia@communicator:~> clang lib.c -shared -o lib.so -fPIC -fuse-ld=bfd
sebastia@communicator:~> clang loadlib.c
sebastia@communicator:~> ./a.out
Program started
Library loaded
sebastia@communicator:~>
since both work, don't know how helpful the objdump will be. I ran objdump -x
on both, find it attached.
Sebastian
objdump_bfd
Description: Binary data
objdump_lld
Description: Binary data
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: loading bundles stopped working
On 28/11/2018 11:35, Sebastian Reitenbach wrote:
(gdb) info break
Num Type Disp Enb AddressWhat
1 breakpoint keep y 0x093f1dcad9a2 in
initialize_gnustep_backend at NSApplication.m:309
breakpoint already hit 1 time
2 breakpoint keep y 0x093ec291a170 in -[NSBundle load] at
NSBundle.m:1989
3 breakpoint keep y 0x093ec2b2a750 in __objc_dynamic_link at
././dynamic-load.h:63
5 breakpoint keep y 0x093e64843ae0 in __objc_exec_class at
/home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/libobjc2-1.9.0/loader.c:46
(gdb) c
Continuing.
Breakpoint 2, -[NSBundle load] (self=0x93e9baac588, _cmd=0x93e69deea88) at
NSBundle.m:1989
1989- (BOOL) load
(gdb)
Continuing.
Breakpoint 3, __objc_dynamic_link (module=0x93f0c45f248 "8\212\273\302>\t", mode=2366,
debug_file=0x93f3d9fa8e0 <__sF+304> "") at ././dynamic-load.h:64
warning: Source file is more recent than executable.
64 {
(gdb)
Continuing.
Program received signal SIGFPE, Arithmetic exception.
0x093e70b4124c in _dl_find_symbol_obj (obj=0x93ecb3bbc00,
sl=0x7f7d33f8) at /usr/src/libexec/ld.so/resolve.c:584
584 for (si = obj->buckets[sl->sl_elf_hash % obj->nbuckets];
So I stopped at NSApplication.m:309, and then added the breakpoints in
dynamic-load.h and in libobjc loader.c where the __objc_exec_class resides, and
then continued to execute, but it doesn't hit the breakpoint 5 before throwing
the FPE.
Okay, it looks as if libraries that are linked with lld are not getting
their global constructors called on OpenBSD. Can you try this test?
=$ cat lib.c
#include
__attribute__((constructor))
void load(void)
{
puts("Library loaded");
}
[theraven@FBSDVM /tmp]$ cat loadlib.c
#include
#include
int main(void)
{
puts("Program started");
dlopen("./lib.so", RTLD_LAZY | RTLD_GLOBAL);
return 0;
}
$ clang60 lib.c -shared -o lib.so -fPIC -fuse-ld=lld
$ clang loadlib.c
$ ./a.out
Program started
Library loaded
If it prints both of the lines above, the library was correctly loaded
and the global constructors were run. If it works with -fuse-ld=lld but
not -fuse-ld=bfd, then that tells us that this really is the problem.
Objdump of the bfd and lld versions of lib.so should help us identify
the differences.
David
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: loading bundles stopped working
Am Dienstag, November 27, 2018 19:26 CET, Matt Rice schrieb: > 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. The thing that changed was the linker, at 22nd of October, the default linker on amd64 platform changed from the good old bfd linker to the lld linker from llvm. As a workaround for the time being, I pass -fuse-ld=bfd, as David suggested, to unbreak all the GNUstep applications in the ports tree. So the lld linker is doing something different to the resulting binary than the old bfd linker did. Will it help to run nm, or objdump or the like on the binary, or the libraries to compare output between what it produces when using lld or bfd linkers? Sebastian > > > > 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
Am Dienstag, November 27, 2018 11:02 CET, David Chisnall
schrieb:
> 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.
Sorry, my update to fix gnustep on openbsd broke some other shit's that I had
to fix first ;)
Now back here:
(gdb) bt
#0 initialize_gnustep_backend () at NSApplication.m:309
#1 0x093f1dcb033b in -[NSApplication _init] (self=0x93ecbd3a008,
_cmd=0x93f1e03eef8 <.objc_selector_list+3232>) at NSApplication.m:878
#2 0x093ec2a28428 in -[NSObject performSelector:withObject:]
(self=0x93ecbd3a008, _cmd=0x93ec2c4f460 <.objc_selector_list+256>,
aSelector=0x93f1e03eef8 <.objc_selector_list+3232>, anObject=0x93ecbd3a008)
at NSObject.m:2000
#3 0x093ec2abe4f3 in -[NSObject(NSThreadPerformAdditions)
performSelector:onThread:withObject:waitUntilDone:modes:] (self=0x93ecbd3a008,
_cmd=0x93ec2c4f5e0 <.objc_selector_list+640>, aSelector=0x93f1e03eef8
<.objc_selector_list+3232>, aThread=0x93ecbd3ae08, anObject=0x93ecbd3a008,
aFlag=1 '\001',
anArray=0x93f1b8f3dc8) at NSThread.m:1672
#4 0x093ec2abe1a0 in -[NSObject(NSThreadPerformAdditions)
performSelectorOnMainThread:withObject:waitUntilDone:modes:]
(self=0x93ecbd3a008,
_cmd=0x93ec2c4f600 <.objc_selector_list+672>, aSelector=0x93f1e03eef8
<.objc_selector_list+3232>, anObject=0x93ecbd3a008, aFlag=1 '\001',
anArray=0x93f1b8f3dc8)
at NSThread.m:1627
#5 0x093ec2abe23e in -[NSObject(NSThreadPerformAdditions)
performSelectorOnMainThread:withObject:waitUntilDone:] (self=0x93ecbd3a008,
_cmd=0x93f1e03f088 <.objc_selector_list+3632>, aSelector=0x93f1e03eef8
<.objc_selector_list+3232>, anObject=0x93ecbd3a008, aFlag=1 '\001') at
NSThread.m:1638
#6 0x093f1dcb0aa5 in -[NSApplication init] (self=0x93ecbd3a008,
_cmd=0x93f1e03f748 <.objc_selector_list+5360>) at NSApplication.m:978
#7 0x093f1dcb02ad in +[NSApplication sharedApplication]
(self=0x93f1e03d8b8 <_OBJC_CLASS_NSApplication>, _cmd=0x93c629652b8
<.objc_selector_list+240>)
at NSApplication.m:850
#8 0x093c62957f95 in gnustep_base_user_main (argc=1, argv=0x7f7d3e68,
env=0x7f7d3e78) at main.m:44
#9 0x093ec2a5c017 in main (argc=1, argv=0x7f7d3e68,
env=0x7f7d3e78) at NSProcessInfo.m:1002
#10 0x093c62954056 in ___start ()
#11 0x in ?? ()
(gdb) info break
Num Type Disp Enb AddressWhat
1 breakpoint keep y 0x093f1dcad9a2 in
initialize_gnustep_backend at NSApplication.m:309
breakpoint already hit 1 time
2 breakpoint keep y 0x093ec291a170 in -[NSBundle load] at
NSBundle.m:1989
3 breakpoint keep y 0x093ec2b2a750 in __objc_dynamic_link at
././dynamic-load.h:63
4 breakpoint keep y 0x093ec2b2a750 in __objc_dynamic_link at
././dynamic-load.h:63
5 breakpoint keep y 0x093e64843ae0 in __objc_exec_class at
/home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/libobjc2-1.9.0/loader.c:46
(gdb) delete 4
(gdb) info break
Num Type Disp Enb AddressWhat
1 breakpoint keep y 0x093f1dcad9a2 in
initialize_gnustep_backend at NSApplication.m:309
breakpoint already hit 1 time
2 breakpoint keep y 0x093ec291a170 in -[NSBundle load] at
NSBundle.m:1989
3 breakpoint keep y 0x093ec2b2a750 in __objc_dynamic_link at
././dynamic-load.h:63
5 breakpoint keep y 0x093e64843ae0 in __objc_exec_class at
/home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/libobjc2-1.9.0/loader.c:46
(gdb) c
Continuing.
Breakpoint 2, -[NSBundle load] (self=0x93e9baac588, _cmd=0x93e69deea88) at
NSBundle.m:1989
1989- (BOOL) load
(gdb)
Continuing.
Breakpoint 3, __objc_dynamic_link (module=0x93f0c45f248 "8\212\273\302>\t",
mode=2366, debug_file=0x93f3d9fa8e0 <__sF+304> "") at ././dynamic-load.h:64
warning: Source file is more recent than executable.
64 {
(gdb)
Continuing.
Program received signal SIGFPE, Arithmetic exception.
0x093e70b4124c in _dl_find_symbol_obj (obj=0x93ecb3bbc00,
sl=0x7f7d33f8) at /usr/src/libexec/ld.so/resolve.c:584
584 for (si = obj->buckets[sl->sl_elf_hash % obj->nbuckets];
So I stopped at
Re: loading bundles stopped working
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
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
Re: loading bundles stopped working
Am Montag, November 26, 2018 16:14 CET, David Chisnall
schrieb:
> 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.
>
> > 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
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??
Sebastian
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (NSApplication.m:309) pending.
(gdb) break NSBundle.m:1989
No source file named NSBundle.m.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (NSBundle.m:1989) pending.
(gdb) break dynamic-load.h:63
No source file named dynamic-load.h.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 3 (dynamic-load.h:63) pending.
(gdb) r
Starting program: /usr/local/bin/GMines
Breakpoint 1, initialize_gnustep_backend () at NSApplication.m:309
309 theBundle = [NSBundle bundleWithPath: path];
(gdb) c
Continuing.
Breakpoint 2, -[NSBundle load] (self=0xda79dff5e08, _cmd=0xda79dff5608) at
NSBundle.m:1989
1989- (BOOL) load
(gdb) c
Continuing.
Breakpoint 3, __objc_dynamic_link (module=0xda7dfb59148 "8*\033k\250\r",
mode=3496,
debug_file=0xda83944f8e0 <__sF+304> "") at ././dynamic-load.h:64
warning: Source file is more recent than executable.
64 {
(gdb) list
59 /* Link in the module given by the name 'module'. Return a handle
which can
60 be used to get information about the loded code.
61 */
62 static dl_handle_t
63 __objc_dynamic_link(const char* module, int mode, const char*
debug_file)
64 {
65 #ifdef RTLD_NOLOAD
66 /*
67 * If we've got RTLD_NOLOAD, then ask the dynamic linker first
to check if
68 * the library is already loaded. If it is, then just return a
handle to
(gdb) n
77 return (dl_handle_t)dlopen(module, RTLD_LAZY | RTLD_GLOBAL);
(gdb) print module
$1 = 0xda79dff5390
"/usr/local/lib/GNUstep/Bundles/libgnustep-back-026.bundle/libgnustep-back-026"
(gdb) s
GSPrivateLoadModule (filename=0xda82c10fd08, errorStream=0xda83944f8e0
<__sF+304>,
loadCallback=0xda86af147c0 <_bundle_load_callback>, header=0x0,
debugFilename=0x0) at objc-load.m:173
173 if (handle == 0)
(gdb) list
168
169 /* Link in the object file */
170 NSDebugFLLog(@"NSBundle", @"Debug (objc-load): Linking file %@\n",
filename);
171 handle = __objc_dynamic_link((FSCHAR*)[filename
fileSystemRepresentation],
172 1, (FSCHAR*)[debugFilename fileSystemRepresentation]);
173 if (handle == 0)
174 {
175 if (errorStream)
176 {
177 __objc_dynamic_error(errorStream, "Error (objc-load)");
(gdb) print handle
$2 = (dl_handle_t) 0xda7eddb7000
(gdb)(gdb) break loader.c:46
Breakpoint 4 at 0xda836645ae0: file
/home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/libobjc2-1.9.0/loader.c, line 46.
(gdb) c
Continuing.
Program received signal SIGFPE, Arithmetic exception.
0x0da7b5b0a24c in _dl_find_symbol_obj (obj=0xda7eddb7000, sl=0x7f7c5678)
at /usr/src/libexec/ld.so/resolve.c:584
584 for (si = obj->buckets[sl->sl_elf_hash % obj->nbuckets];
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: loading bundles stopped working
Am Montag, November 26, 2018 12:22 CET, David Chisnall
schrieb:
> On 26/11/2018 08:47, Sebastian Reitenbach wrote:
> > Program received signal SIGFPE, Arithmetic exception.
> > 0x0527770d024c in _dl_find_symbol_obj (obj=0x52722e05c00,
> > sl=0x7f7f5108) at /usr/src/libexec/ld.so/resolve.c:584
> > 584 for (si = obj->buckets[sl->sl_elf_hash % obj->nbuckets];
> > (gdb) bt
> > #0 0x0527770d024c in _dl_find_symbol_obj (obj=0x52722e05c00,
> > sl=0x7f7f5108) at /usr/src/libexec/ld.so/resolve.c:584
> > #1 0x0527770d0068 in _dl_find_symbol (name=0x526ae984ea5 "getpid",
> > this=0x7f7f51a8, flags=48, ref_sym=0x526ae9194c8, req_obj= > out>, pobj=0x7f7f51a0)
> > at /usr/src/libexec/ld.so/resolve.c:663
> > #2 0x0527770cef1a in _dl_bind (object=0x526d8585800, index= > out>) at /usr/src/libexec/ld.so/amd64/rtld_machine.c:357
> > #3 0x0527770d0fed 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
Re: loading bundles stopped working
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. 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
Re: loading bundles stopped working
On 26/11/2018 08:47, Sebastian Reitenbach wrote: Program received signal SIGFPE, Arithmetic exception. 0x0527770d024c in _dl_find_symbol_obj (obj=0x52722e05c00, sl=0x7f7f5108) at /usr/src/libexec/ld.so/resolve.c:584 584 for (si = obj->buckets[sl->sl_elf_hash % obj->nbuckets]; (gdb) bt #0 0x0527770d024c in _dl_find_symbol_obj (obj=0x52722e05c00, sl=0x7f7f5108) at /usr/src/libexec/ld.so/resolve.c:584 #1 0x0527770d0068 in _dl_find_symbol (name=0x526ae984ea5 "getpid", this=0x7f7f51a8, flags=48, ref_sym=0x526ae9194c8, req_obj=, pobj=0x7f7f51a0) at /usr/src/libexec/ld.so/resolve.c:663 #2 0x0527770cef1a in _dl_bind (object=0x526d8585800, index=) at /usr/src/libexec/ld.so/amd64/rtld_machine.c:357 #3 0x0527770d0fed 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 Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: loading bundles stopped working
Hi, Am Sonntag, November 25, 2018 21:22 CET, David Chisnall schrieb: > On 25 Nov 2018, at 18:30, Sebastian Reitenbach > wrote: > > > > So, the thing is, when I replace all /usr/bin/ld* with the /usr/bin/ld.bfd, > > and rebuild everything, > > then GUI apps, as well as SOGo start up. But I can't do that when building > > packages :( > > You can do that with -fuse-ld=bfd in LDFLAGS, but I agree it’s not the right > solution. This workaround is good for the time being getting things to work again. > > The bugs that you’re seeing look as if they may be symptoms of the hash table > bugs that I fixed in libobjc2 a month or two ago. Can you check if they’re > still there with the 1.9 release branch? Installing the 1.9 branch doesn't seem to help, the error persists. First when creating the package for the 1.9 branch, I got some error when the ports infrastructued atempted to install it into the fake-root: ===> Faking installation for gnustep-libobjc2-1.9.0 [0/1] cd /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/build-amd64 && /usr/local/bin/cmake -P cmake_install.cmake -- Install configuration: "Release" -- Installing: /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/fake-amd64/usr/local/lib/libobjc2.so.1.1 -- Installing: /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/fake-amd64/usr/local/lib/libobjc2.a -- Installing: /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/fake-amd64/usr/local/include/gnustep/objc/Availability.h -- Installing: /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/fake-amd64/usr/local/include/gnustep/objc/Object.h -- Installing: /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/fake-amd64/usr/local/include/gnustep/objc/Protocol.h -- Installing: /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/fake-amd64/usr/local/include/gnustep/objc/blocks_private.h -- Installing: /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/fake-amd64/usr/local/include/gnustep/objc/blocks_runtime.h -- Installing: /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/fake-amd64/usr/local/include/gnustep/objc/capabilities.h -- Installing: /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/fake-amd64/usr/local/include/gnustep/objc/developer.h -- Installing: /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/fake-amd64/usr/local/include/gnustep/objc/encoding.h -- Installing: /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/fake-amd64/usr/local/include/gnustep/objc/hooks.h -- Installing: /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/fake-amd64/usr/local/include/gnustep/objc/message.h -- Installing: /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/fake-amd64/usr/local/include/gnustep/objc/objc-api.h -- Installing: /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/fake-amd64/usr/local/include/gnustep/objc/objc-arc.h -- Installing: /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/fake-amd64/usr/local/include/gnustep/objc/objc-auto.h -- Installing: /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/fake-amd64/usr/local/include/gnustep/objc/objc-class.h -- Installing: /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/fake-amd64/usr/local/include/gnustep/objc/objc-runtime.h -- Installing: /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/fake-amd64/usr/local/include/gnustep/objc/objc.h -- Installing: /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/fake-amd64/usr/local/include/gnustep/objc/runtime-deprecated.h -- Installing: /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/fake-amd64/usr/local/include/gnustep/objc/runtime.h -- Installing: /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/fake-amd64/usr/local/include/gnustep/objc/slot.h failed to create symbolic link 'include/Block.h': No such file or directory -- Symlinking: include/Block.h -> include/gnustep/objc/blocks_runtime.h failed to create symbolic link 'include/Block_private.h': No such file or directory -- Symlinking: include/Block_private.h -> include/gnustep/objc/blocks_private.h sebastia@communicator:/home/ports/x11/gnustep/libobjc2> find /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0 -name Block.h sebastia@communicator:/home/ports/x11/gnustep/libobjc2> find /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0 -name blocks_runtime.h /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/libobjc2-1.9.0/blocks_runtime.h /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/libobjc2-1.9.0/objc/blocks_runtime.h /home/ports/pobj/amd64/gnustep-libobjc2-1.9.0/fake-amd64/usr/local/include/gnustep/objc/blocks_runtime.h In order to get me going, I created this symlink, and the Block_private.h symlink manually, and commented out the two lines creating the symlinks from the CMakeLists.txt file. With that manual editing I got the 1.9 branch installed, and rebuilt all the rest of GNUstep. However, the problem is still there, see new stepping through gdb at the end. Let me know if there is any more info I can provide, or if there is something else I should test. thanks, Sebastian sebastia@communicator:/tmp> egdb /usr/local/bin/GMines
Re: loading bundles stopped working
On 25 Nov 2018, at 18:30, Sebastian Reitenbach wrote: > > So, the thing is, when I replace all /usr/bin/ld* with the /usr/bin/ld.bfd, > and rebuild everything, > then GUI apps, as well as SOGo start up. But I can't do that when building > packages :( You can do that with -fuse-ld=bfd in LDFLAGS, but I agree it’s not the right solution. The bugs that you’re seeing look as if they may be symptoms of the hash table bugs that I fixed in libobjc2 a month or two ago. Can you check if they’re still there with the 1.9 release branch? David ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
