Linux/Clang/Libobjc2 failure part 2 (ng)

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Linux/Clang/Libobjc2 failure part 2 (ng)

Riccardo Mottola-5
Hi all,

on the same system Linux/Clang/libobjc2, I tried reconfiguring
everything and rebuilt everything using the Next Gen runtime.

I configured make with:
$ ./configure --prefix=/ --with-layout=gnustep
--with-library-combo=ng-gnu-gnu
  CC=clang CXX=clang++


and then reconfigured/rebuilt everything else.

However GUI apps still crash badly.

I get this:
Program received signal SIGSEGV, Segmentation fault.
0xb74782df in GSPrivateFormat (s=<optimized out>, format=<optimized out>,
     ap=0xbfffed00
"\200\211\205\267\214\211\205\267T\216\205\267\350\201\205\267\217\rL\267\200\066\017\bP=M\267\204\177\205\267\220\177\205\267T\216\205\267\260\200\205\267\244\200\205\267\224\271\061\b\256+d\267x\177\205\267P\200\205\267D\200\205\267\070\200\205\267,\200\205\267
\200\205\267\024\200\205\267l\177\205\267\b\200\205\267\374\177\205\267\360\177\205\267\344\177\205\267\330\177\205\267\300\177\205\267\314\177\205\267\264\177\205\267\234\177\205\267L\201\205\267@\201\205\267\064\201\205\267(\201\205\267\034\201\205\267\020\201\205\267\004\201\205\267\370\200\205\267\354\200\205\267\200\200\205\267\340\200\205\267t\200\205\267\324\200\205\267\310\200\205\267\230\200\205\267\214\200\205\267\\\200\205\267\274\200\205\267<\216\205\267"...,
locale=<optimized out>) at GSFormat.m:910
910           workend = &work_buffer[sizeof (work_buffer) / sizeof
(unichar)];
(gdb) bt
#0  0xb74782df in GSPrivateFormat (s=<optimized out>, format=<optimized
out>,
     ap=0xbfffed00
"\200\211\205\267\214\211\205\267T\216\205\267\350\201\205\267\217\rL\267\200\066\017\bP=M\267\204\177\205\267\220\177\205\267T\216\205\267\260\200\205\267\244\200\205\267\224\271\061\b\256+d\267x\177\205\267P\200\205\267D\200\205\267\070\200\205\267,\200\205\267
\200\205\267\024\200\205\267l\177\205\267\b\200\205\267\374\177\205\267\360\177\205\267\344\177\205\267\330\177\205\267\300\177\205\267\314\177\205\267\264\177\205\267\234\177\205\267L\201\205\267@\201\205\267\064\201\205\267(\201\205\267\034\201\205\267\020\201\205\267\004\201\205\267\370\200\205\267\354\200\205\267\200\200\205\267\340\200\205\267t\200\205\267\324\200\205\267\310\200\205\267\230\200\205\267\214\200\205\267\\\200\205\267\274\200\205\267<\216\205\267"...,
locale=<optimized out>) at GSFormat.m:910
#1  0xb748e404 in -[GSPlaceholderString initWithFormat:locale:arguments:] (
     self=<optimized out>, _cmd=0xb788f478 <.objc_selector_list+272>,
     format=<optimized out>, locale=<optimized out>, argList=<optimized
out>)
     at GSString.m:1618
#2  0xb75abc32 in -[NSString initWithFormat:] (self=<optimized out>,
     _cmd=<optimized out>, format=<optimized out>) at NSString.m:1343
#3  0xb74c160c in +[NSBundle initialize] (self=<optimized out>,
     _cmd=<optimized out>) at NSBundle.m:1180
#4  0xb72e1179 in objc_send_initialize ()
    from /System/Library/Libraries/libobjc.so.4.6
#5  0xb72ef4e8 in slowMsgLookup ()
    from /System/Library/Libraries/libobjc.so.4.6


However, if I recompile base with "debug=yes" the issue looks totally
different!
This almost looks like a X11/back issue, or at least, the crash happens
inside there, but it could be an effect.

Any ideas??


#0  0xb3fbb141 in xcb_writev () from /usr/lib/libxcb.so.1
#1  0xb41740f2 in _XSend () from /usr/lib/libX11.so.6
#2  0xb41746ad in _XReply () from /usr/lib/libX11.so.6
#3  0xb415a170 in XGetWindowProperty () from /usr/lib/libX11.so.6
#4  0xb4158f54 in XGetIconSizes () from /usr/lib/libX11.so.6
#5  0xb454ccb9 in -[XGServer(WindowOps) iconSize] (self=<optimized out>,
     _cmd=0xb7f76e98 <.objc_selector_list+72>) at XGServerWindow.m:4565
#6  0xb7cea457 in GSGetIconSize () at GSIconManager.m:88
#7  0xb7b487c0 in +[NSAppIconView initialize] (self=<optimized out>,
     _cmd=<optimized out>) at NSApplication.m:526
#8  0xb7243179 in objc_send_initialize ()
    from /System/Library/Libraries/libobjc.so.4.6
#9  0xb72514e8 in slowMsgLookup ()
    from /System/Library/Libraries/libobjc.so.4.6
#10 0xb7255251 in objc_msgSend () from
/System/Library/Libraries/libobjc.so.4.6
#11 0xb7b4fea9 in -[NSApplication(Private) _appIconInit] (
     self=<optimized out>, _cmd=<optimized out>) at NSApplication.m:3863
#12 0xb7b49915 in -[NSApplication _init] (self=0x8377c94,
     _cmd=0xb7eac120 <.objc_selector_list+1344>) at NSApplication.m:924
#13 0xb75563c2 in -[NSObject performSelector:withObject:] (self=0x8377c94,
     _cmd=0xb788f848 <.objc_selector_list+424>,
     aSelector=0xb7eac120 <.objc_selector_list+1344>, anObject=0x8377c94)
     at NSObject.m:2009
#14 0xb75ec255 in -[NSObject(NSThreadPerformAdditions)
performSelector:onThread:withObject:waitUntilDone:modes:] (self=0x8377c94,
     _cmd=0xb788f7a0 <.objc_selector_list+256>,
     aSelector=0xb7eac120 <.objc_selector_list+1344>, aThread=0x82ffa84,
     anObject=0x8377c94, aFlag=1 '\001', anArray=0x8379634) at
NSThread.m:2136
#15 0xb75ebedf in -[NSObject(NSThreadPerformAdditions)
performSelectorOnMainThread:withObject:waitUntilDone:modes:]
(self=0x8377c94,
     _cmd=0xb788f7b8 <.objc_selector_list+280>,
     aSelector=0xb7eac120 <.objc_selector_list+1344>, anObject=0x8377c94,
     aFlag=1 '\001', anArray=0x8379634) at NSThread.m:2091
#16 0xb75ebf84 in -[NSObject(NSThreadPerformAdditions)
performSelectorOnMainThread:withObject:waitUntilDone:] (self=0x8377c94,
     _cmd=0xb7eac5d8 <.objc_selector_list+2552>,
     aSelector=0xb7eac120 <.objc_selector_list+1344>, anObject=0x8377c94,
     aFlag=1 '\001') at NSThread.m:2102
#17 0xb7b49ccf in -[NSApplication init] (self=0x8377c94, _cmd=<optimized
out>)
     at NSApplication.m:978
#18 0xb7b49641 in +[NSApplication sharedApplication] (self=<optimized out>,
     _cmd=<optimized out>) at NSApplication.m:850
#19 0xb7b30266 in NSApplicationMain (argc=<optimized out>,
     argv=<optimized out>) at Functions.m:78
#20 0x08050400 in main (argc=<optimized out>, argv=<optimized out>)
     at main.m:30


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Linux/Clang/Libobjc2 failure part 2 (ng)

Riccardo Mottola-5
Hi all,

on the same Linux system, if I switch to gcc with its own runtime,
everything works.
The libxcb/libX11 issue does not reproduce in that case, which hints to
a more generic memory issue and not a X backend issue.
Thus, essentially I cannot use libobjc2 in either configuration.
I have also a FreeBSD system in similar situation, but there GCC doesn't
have its runtime, so I cannot test that. However there the "gnu" mode
doesn't work, but the nex-gen does.
Very tricky?

Riccardo

On 22/06/2018 15:13, Riccardo Mottola wrote:

> Hi all,
>
> on the same system Linux/Clang/libobjc2, I tried reconfiguring
> everything and rebuilt everything using the Next Gen runtime.
>
> I configured make with:
> $ ./configure --prefix=/ --with-layout=gnustep
> --with-library-combo=ng-gnu-gnu
>  CC=clang CXX=clang++
>
>
> and then reconfigured/rebuilt everything else.
>
> However GUI apps still crash badly.
>
> I get this:
> Program received signal SIGSEGV, Segmentation fault.
> 0xb74782df in GSPrivateFormat (s=<optimized out>, format=<optimized out>,
>     ap=0xbfffed00
> "\200\211\205\267\214\211\205\267T\216\205\267\350\201\205\267\217\rL\267\200\066\017\bP=M\267\204\177\205\267\220\177\205\267T\216\205\267\260\200\205\267\244\200\205\267\224\271\061\b\256+d\267x\177\205\267P\200\205\267D\200\205\267\070\200\205\267,\200\205\267
> \200\205\267\024\200\205\267l\177\205\267\b\200\205\267\374\177\205\267\360\177\205\267\344\177\205\267\330\177\205\267\300\177\205\267\314\177\205\267\264\177\205\267\234\177\205\267L\201\205\267@\201\205\267\064\201\205\267(\201\205\267\034\201\205\267\020\201\205\267\004\201\205\267\370\200\205\267\354\200\205\267\200\200\205\267\340\200\205\267t\200\205\267\324\200\205\267\310\200\205\267\230\200\205\267\214\200\205\267\\\200\205\267\274\200\205\267<\216\205\267"...,
> locale=<optimized out>) at GSFormat.m:910
> 910           workend = &work_buffer[sizeof (work_buffer) / sizeof
> (unichar)];
> (gdb) bt
> #0  0xb74782df in GSPrivateFormat (s=<optimized out>,
> format=<optimized out>,
>     ap=0xbfffed00
> "\200\211\205\267\214\211\205\267T\216\205\267\350\201\205\267\217\rL\267\200\066\017\bP=M\267\204\177\205\267\220\177\205\267T\216\205\267\260\200\205\267\244\200\205\267\224\271\061\b\256+d\267x\177\205\267P\200\205\267D\200\205\267\070\200\205\267,\200\205\267
> \200\205\267\024\200\205\267l\177\205\267\b\200\205\267\374\177\205\267\360\177\205\267\344\177\205\267\330\177\205\267\300\177\205\267\314\177\205\267\264\177\205\267\234\177\205\267L\201\205\267@\201\205\267\064\201\205\267(\201\205\267\034\201\205\267\020\201\205\267\004\201\205\267\370\200\205\267\354\200\205\267\200\200\205\267\340\200\205\267t\200\205\267\324\200\205\267\310\200\205\267\230\200\205\267\214\200\205\267\\\200\205\267\274\200\205\267<\216\205\267"...,
> locale=<optimized out>) at GSFormat.m:910
> #1  0xb748e404 in -[GSPlaceholderString
> initWithFormat:locale:arguments:] (
>     self=<optimized out>, _cmd=0xb788f478 <.objc_selector_list+272>,
>     format=<optimized out>, locale=<optimized out>, argList=<optimized
> out>)
>     at GSString.m:1618
> #2  0xb75abc32 in -[NSString initWithFormat:] (self=<optimized out>,
>     _cmd=<optimized out>, format=<optimized out>) at NSString.m:1343
> #3  0xb74c160c in +[NSBundle initialize] (self=<optimized out>,
>     _cmd=<optimized out>) at NSBundle.m:1180
> #4  0xb72e1179 in objc_send_initialize ()
>    from /System/Library/Libraries/libobjc.so.4.6
> #5  0xb72ef4e8 in slowMsgLookup ()
>    from /System/Library/Libraries/libobjc.so.4.6
>
>
> However, if I recompile base with "debug=yes" the issue looks totally
> different!
> This almost looks like a X11/back issue, or at least, the crash
> happens inside there, but it could be an effect.
>
> Any ideas??
>
>
> #0  0xb3fbb141 in xcb_writev () from /usr/lib/libxcb.so.1
> #1  0xb41740f2 in _XSend () from /usr/lib/libX11.so.6
> #2  0xb41746ad in _XReply () from /usr/lib/libX11.so.6
> #3  0xb415a170 in XGetWindowProperty () from /usr/lib/libX11.so.6
> #4  0xb4158f54 in XGetIconSizes () from /usr/lib/libX11.so.6
> #5  0xb454ccb9 in -[XGServer(WindowOps) iconSize] (self=<optimized out>,
>     _cmd=0xb7f76e98 <.objc_selector_list+72>) at XGServerWindow.m:4565
> #6  0xb7cea457 in GSGetIconSize () at GSIconManager.m:88
> #7  0xb7b487c0 in +[NSAppIconView initialize] (self=<optimized out>,
>     _cmd=<optimized out>) at NSApplication.m:526
> #8  0xb7243179 in objc_send_initialize ()
>    from /System/Library/Libraries/libobjc.so.4.6
> #9  0xb72514e8 in slowMsgLookup ()
>    from /System/Library/Libraries/libobjc.so.4.6
> #10 0xb7255251 in objc_msgSend () from
> /System/Library/Libraries/libobjc.so.4.6
> #11 0xb7b4fea9 in -[NSApplication(Private) _appIconInit] (
>     self=<optimized out>, _cmd=<optimized out>) at NSApplication.m:3863
> #12 0xb7b49915 in -[NSApplication _init] (self=0x8377c94,
>     _cmd=0xb7eac120 <.objc_selector_list+1344>) at NSApplication.m:924
> #13 0xb75563c2 in -[NSObject performSelector:withObject:]
> (self=0x8377c94,
>     _cmd=0xb788f848 <.objc_selector_list+424>,
>     aSelector=0xb7eac120 <.objc_selector_list+1344>, anObject=0x8377c94)
>     at NSObject.m:2009
> #14 0xb75ec255 in -[NSObject(NSThreadPerformAdditions)
> performSelector:onThread:withObject:waitUntilDone:modes:]
> (self=0x8377c94,
>     _cmd=0xb788f7a0 <.objc_selector_list+256>,
>     aSelector=0xb7eac120 <.objc_selector_list+1344>, aThread=0x82ffa84,
>     anObject=0x8377c94, aFlag=1 '\001', anArray=0x8379634) at
> NSThread.m:2136
> #15 0xb75ebedf in -[NSObject(NSThreadPerformAdditions)
> performSelectorOnMainThread:withObject:waitUntilDone:modes:]
> (self=0x8377c94,
>     _cmd=0xb788f7b8 <.objc_selector_list+280>,
>     aSelector=0xb7eac120 <.objc_selector_list+1344>, anObject=0x8377c94,
>     aFlag=1 '\001', anArray=0x8379634) at NSThread.m:2091
> #16 0xb75ebf84 in -[NSObject(NSThreadPerformAdditions)
> performSelectorOnMainThread:withObject:waitUntilDone:] (self=0x8377c94,
>     _cmd=0xb7eac5d8 <.objc_selector_list+2552>,
>     aSelector=0xb7eac120 <.objc_selector_list+1344>, anObject=0x8377c94,
>     aFlag=1 '\001') at NSThread.m:2102
> #17 0xb7b49ccf in -[NSApplication init] (self=0x8377c94,
> _cmd=<optimized out>)
>     at NSApplication.m:978
> #18 0xb7b49641 in +[NSApplication sharedApplication] (self=<optimized
> out>,
>     _cmd=<optimized out>) at NSApplication.m:850
> #19 0xb7b30266 in NSApplicationMain (argc=<optimized out>,
>     argv=<optimized out>) at Functions.m:78
> #20 0x08050400 in main (argc=<optimized out>, argv=<optimized out>)
>     at main.m:30
>
>
> _______________________________________________
> Discuss-gnustep mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Linux/Clang/Libobjc2 failure part 2 (ng)

David Chisnall-7
Hi,

This might be the issue with the Linux run-time linker’s failure to merge the ivar guess variables.  Can you try with this patch?

http://lists.gnu.org/archive/html/discuss-gnustep/2017-12/msg00129.html

This isn’t needed with the v2 ABI, but I need help fixing the issues with GNUstep’s NSString implementation before I can recommend enabling that for GNUstep, because the new NSConstantString representation exposes a lot of bugs in -base’s unicode string handling.

David

> On 24 Jun 2018, at 06:30, Riccardo Mottola <[hidden email]> wrote:
>
> Hi all,
>
> on the same Linux system, if I switch to gcc with its own runtime, everything works.
> The libxcb/libX11 issue does not reproduce in that case, which hints to a more generic memory issue and not a X backend issue.
> Thus, essentially I cannot use libobjc2 in either configuration.
> I have also a FreeBSD system in similar situation, but there GCC doesn't have its runtime, so I cannot test that. However there the "gnu" mode doesn't work, but the nex-gen does.
> Very tricky?
>
> Riccardo
>
> On 22/06/2018 15:13, Riccardo Mottola wrote:
>> Hi all,
>>
>> on the same system Linux/Clang/libobjc2, I tried reconfiguring everything and rebuilt everything using the Next Gen runtime.
>>
>> I configured make with:
>> $ ./configure --prefix=/ --with-layout=gnustep --with-library-combo=ng-gnu-gnu
>>  CC=clang CXX=clang++
>>
>>
>> and then reconfigured/rebuilt everything else.
>>
>> However GUI apps still crash badly.
>>
>> I get this:
>> Program received signal SIGSEGV, Segmentation fault.
>> 0xb74782df in GSPrivateFormat (s=<optimized out>, format=<optimized out>,
>>     ap=0xbfffed00 "\200\211\205\267\214\211\205\267T\216\205\267\350\201\205\267\217\rL\267\200\066\017\bP=M\267\204\177\205\267\220\177\205\267T\216\205\267\260\200\205\267\244\200\205\267\224\271\061\b\256+d\267x\177\205\267P\200\205\267D\200\205\267\070\200\205\267,\200\205\267 \200\205\267\024\200\205\267l\177\205\267\b\200\205\267\374\177\205\267\360\177\205\267\344\177\205\267\330\177\205\267\300\177\205\267\314\177\205\267\264\177\205\267\234\177\205\267L\201\205\267@\201\205\267\064\201\205\267(\201\205\267\034\201\205\267\020\201\205\267\004\201\205\267\370\200\205\267\354\200\205\267\200\200\205\267\340\200\205\267t\200\205\267\324\200\205\267\310\200\205\267\230\200\205\267\214\200\205\267\\\200\205\267\274\200\205\267<\216\205\267"..., locale=<optimized out>) at GSFormat.m:910
>> 910           workend = &work_buffer[sizeof (work_buffer) / sizeof (unichar)];
>> (gdb) bt
>> #0  0xb74782df in GSPrivateFormat (s=<optimized out>, format=<optimized out>,
>>     ap=0xbfffed00 "\200\211\205\267\214\211\205\267T\216\205\267\350\201\205\267\217\rL\267\200\066\017\bP=M\267\204\177\205\267\220\177\205\267T\216\205\267\260\200\205\267\244\200\205\267\224\271\061\b\256+d\267x\177\205\267P\200\205\267D\200\205\267\070\200\205\267,\200\205\267 \200\205\267\024\200\205\267l\177\205\267\b\200\205\267\374\177\205\267\360\177\205\267\344\177\205\267\330\177\205\267\300\177\205\267\314\177\205\267\264\177\205\267\234\177\205\267L\201\205\267@\201\205\267\064\201\205\267(\201\205\267\034\201\205\267\020\201\205\267\004\201\205\267\370\200\205\267\354\200\205\267\200\200\205\267\340\200\205\267t\200\205\267\324\200\205\267\310\200\205\267\230\200\205\267\214\200\205\267\\\200\205\267\274\200\205\267<\216\205\267"..., locale=<optimized out>) at GSFormat.m:910
>> #1  0xb748e404 in -[GSPlaceholderString initWithFormat:locale:arguments:] (
>>     self=<optimized out>, _cmd=0xb788f478 <.objc_selector_list+272>,
>>     format=<optimized out>, locale=<optimized out>, argList=<optimized out>)
>>     at GSString.m:1618
>> #2  0xb75abc32 in -[NSString initWithFormat:] (self=<optimized out>,
>>     _cmd=<optimized out>, format=<optimized out>) at NSString.m:1343
>> #3  0xb74c160c in +[NSBundle initialize] (self=<optimized out>,
>>     _cmd=<optimized out>) at NSBundle.m:1180
>> #4  0xb72e1179 in objc_send_initialize ()
>>    from /System/Library/Libraries/libobjc.so.4.6
>> #5  0xb72ef4e8 in slowMsgLookup ()
>>    from /System/Library/Libraries/libobjc.so.4.6
>>
>>
>> However, if I recompile base with "debug=yes" the issue looks totally different!
>> This almost looks like a X11/back issue, or at least, the crash happens inside there, but it could be an effect.
>>
>> Any ideas??
>>
>>
>> #0  0xb3fbb141 in xcb_writev () from /usr/lib/libxcb.so.1
>> #1  0xb41740f2 in _XSend () from /usr/lib/libX11.so.6
>> #2  0xb41746ad in _XReply () from /usr/lib/libX11.so.6
>> #3  0xb415a170 in XGetWindowProperty () from /usr/lib/libX11.so.6
>> #4  0xb4158f54 in XGetIconSizes () from /usr/lib/libX11.so.6
>> #5  0xb454ccb9 in -[XGServer(WindowOps) iconSize] (self=<optimized out>,
>>     _cmd=0xb7f76e98 <.objc_selector_list+72>) at XGServerWindow.m:4565
>> #6  0xb7cea457 in GSGetIconSize () at GSIconManager.m:88
>> #7  0xb7b487c0 in +[NSAppIconView initialize] (self=<optimized out>,
>>     _cmd=<optimized out>) at NSApplication.m:526
>> #8  0xb7243179 in objc_send_initialize ()
>>    from /System/Library/Libraries/libobjc.so.4.6
>> #9  0xb72514e8 in slowMsgLookup ()
>>    from /System/Library/Libraries/libobjc.so.4.6
>> #10 0xb7255251 in objc_msgSend () from /System/Library/Libraries/libobjc.so.4.6
>> #11 0xb7b4fea9 in -[NSApplication(Private) _appIconInit] (
>>     self=<optimized out>, _cmd=<optimized out>) at NSApplication.m:3863
>> #12 0xb7b49915 in -[NSApplication _init] (self=0x8377c94,
>>     _cmd=0xb7eac120 <.objc_selector_list+1344>) at NSApplication.m:924
>> #13 0xb75563c2 in -[NSObject performSelector:withObject:] (self=0x8377c94,
>>     _cmd=0xb788f848 <.objc_selector_list+424>,
>>     aSelector=0xb7eac120 <.objc_selector_list+1344>, anObject=0x8377c94)
>>     at NSObject.m:2009
>> #14 0xb75ec255 in -[NSObject(NSThreadPerformAdditions) performSelector:onThread:withObject:waitUntilDone:modes:] (self=0x8377c94,
>>     _cmd=0xb788f7a0 <.objc_selector_list+256>,
>>     aSelector=0xb7eac120 <.objc_selector_list+1344>, aThread=0x82ffa84,
>>     anObject=0x8377c94, aFlag=1 '\001', anArray=0x8379634) at NSThread.m:2136
>> #15 0xb75ebedf in -[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:modes:] (self=0x8377c94,
>>     _cmd=0xb788f7b8 <.objc_selector_list+280>,
>>     aSelector=0xb7eac120 <.objc_selector_list+1344>, anObject=0x8377c94,
>>     aFlag=1 '\001', anArray=0x8379634) at NSThread.m:2091
>> #16 0xb75ebf84 in -[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:] (self=0x8377c94,
>>     _cmd=0xb7eac5d8 <.objc_selector_list+2552>,
>>     aSelector=0xb7eac120 <.objc_selector_list+1344>, anObject=0x8377c94,
>>     aFlag=1 '\001') at NSThread.m:2102
>> #17 0xb7b49ccf in -[NSApplication init] (self=0x8377c94, _cmd=<optimized out>)
>>     at NSApplication.m:978
>> #18 0xb7b49641 in +[NSApplication sharedApplication] (self=<optimized out>,
>>     _cmd=<optimized out>) at NSApplication.m:850
>> #19 0xb7b30266 in NSApplicationMain (argc=<optimized out>,
>>     argv=<optimized out>) at Functions.m:78
>> #20 0x08050400 in main (argc=<optimized out>, argv=<optimized out>)
>>     at main.m:30
>>
>>
>> _______________________________________________
>> Discuss-gnustep mailing list
>> [hidden email]
>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
>
>
> _______________________________________________
> Discuss-gnustep mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
>


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Linux/Clang/Libobjc2 failure part 2 (ng)

Fred Kiefer
Hi David,

> Am 24.06.2018 um 11:17 schrieb David Chisnall <[hidden email]>:
>
> This isn’t needed with the v2 ABI, but I need help fixing the issues with GNUstep’s NSString implementation before I can recommend enabling that for GNUstep, because the new NSConstantString representation exposes a lot of bugs in -base’s unicode string handling.


I am willing to help you with this. As far as I understand some of methods on NSString are not properly implemented based on the two primitive methods length and characterAtIndex:. Here it would help if you pointed me to the already known incomplete methods. I am not planing to use clang or your new libobjc branch so I will have to work without testing, just by code inspection.

Cheers
Fred
_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Linux/Clang/Libobjc2 failure part 2 (ng)

David Chisnall-7
On 24 Jun 2018, at 17:27, Fred Kiefer <[hidden email]> wrote:
>
> Hi David,
>
>> Am 24.06.2018 um 11:17 schrieb David Chisnall <[hidden email]>:
>>
>> This isn’t needed with the v2 ABI, but I need help fixing the issues with GNUstep’s NSString implementation before I can recommend enabling that for GNUstep, because the new NSConstantString representation exposes a lot of bugs in -base’s unicode string handling.
>
>
> I am willing to help you with this. As far as I understand some of methods on NSString are not properly implemented based on the two primitive methods length and characterAtIndex:. Here it would help if you pointed me to the already known incomplete methods. I am not planing to use clang or your new libobjc branch so I will have to work without testing, just by code inspection.

I’ve done some things in the newabi branch that get the correct behaviour, but almost certainly at the cost of performance (and I don’t have anything that is particularly string-intensive to benchmark with to evaluate this) by just using libicu to implement the concrete subclass and providing a few wrappers.  You can test for correctness quite easily by disabling the GS special cases and checking the test suite.  

David


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Linux/Clang/Libobjc2 failure part 2 (ng)

Riccardo Mottola-5
In reply to this post by David Chisnall-7
Hi David!


thanks for replying.


On 24/06/2018 11:17, David Chisnall wrote:
> This might be the issue with the Linux run-time linker’s failure to merge the ivar guess variables.  Can you try with this patch?
>
> http://lists.gnu.org/archive/html/discuss-gnustep/2017-12/msg00129.html
>
> This isn’t needed with the v2 ABI, but I need help fixing the issues with GNUstep’s NSString implementation before I can recommend enabling that for GNUstep, because the new NSConstantString representation exposes a lot of bugs in -base’s unicode string handling.


The patch doesn't apply clean anymore, the code looks changed enough!

there is no objc_test_class_flag(class, objc_class_flag_new_abi)
anymore? Where should I call objc_test_class_flag(class,
objc_class_flag_new_abi)) now? please check and perhaps update the patch
to your changes, so I can test it.

Riccardo

_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Linux/Clang/Libobjc2 failure part 2 (ng)

David Chisnall-7
On 24 Jun 2018, at 21:28, Riccardo Mottola <[hidden email]> wrote:
>
> The patch doesn't apply clean anymore, the code looks changed enough!
>
> there is no objc_test_class_flag(class, objc_class_flag_new_abi) anymore? Where should I call objc_test_class_flag(class, objc_class_flag_new_abi)) now? please check and perhaps update the patch to your changes, so I can test it.

Ah, sorry.  The newer structure of the runtime upgrades all class structures to the modern one in a single place.  If you call objc_legacy_class_for_class() and it doesn’t return anything, then it’s a GNUstep ABIv2 class, but you shouldn’t need to do that - you can just unconditionally set the offset variable that dlsym finds to the correct offset, if it finds a symbol.

David


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Linux/Clang/Libobjc2 failure part 2 (ng)

Riccardo Mottola-5
Hi,

On 2018-06-25 11:16:44 +0200 David Chisnall <[hidden email]> wrote:

> On 24 Jun 2018, at 21:28, Riccardo Mottola <[hidden email]> wrote:
>
>> The patch doesn't apply clean anymore, the code looks changed enough!
>
>> there is no objc_test_class_flag(class, objc_class_flag_new_abi) anymore?
>> Where should I call objc_test_class_flag(class, objc_class_flag_new_abi))
>> now? please check and perhaps update the patch to your changes, so I can
>> test it.
>
> Ah, sorry.  The newer structure of the runtime upgrades all class structures
> to the modern one in a single place.  If you call
> objc_legacy_class_for_class() and it doesn’t return anything, then it’s a
> GNUstep ABIv2 class, but you shouldn’t need to do that - you can just
> unconditionally set the offset variable that dlsym finds to the correct
> offset, if it finds a symbol.


sorry.. I tried that at the end of the loop, insrting the same code the patch had.
But apparently ivars_offset[] is not found in objc_class struct.

I want to be sure to test the correct thing. If you can make me the patch clean, I can test it.

Thank you,

Riccardo


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Linux/Clang/Libobjc2 failure part 2 (ng)

Fred Kiefer
In reply to this post by David Chisnall-7


> Am 24.06.2018 um 20:23 schrieb David Chisnall <[hidden email]>:
>
> On 24 Jun 2018, at 17:27, Fred Kiefer <[hidden email]> wrote:
>>
>> Hi David,
>>
>>> Am 24.06.2018 um 11:17 schrieb David Chisnall <[hidden email]>:
>>>
>>> This isn’t needed with the v2 ABI, but I need help fixing the issues with GNUstep’s NSString implementation before I can recommend enabling that for GNUstep, because the new NSConstantString representation exposes a lot of bugs in -base’s unicode string handling.
>>
>>
>> I am willing to help you with this. As far as I understand some of methods on NSString are not properly implemented based on the two primitive methods length and characterAtIndex:. Here it would help if you pointed me to the already known incomplete methods. I am not planing to use clang or your new libobjc branch so I will have to work without testing, just by code inspection.
>
> I’ve done some things in the newabi branch that get the correct behaviour, but almost certainly at the cost of performance (and I don’t have anything that is particularly string-intensive to benchmark with to evaluate this) by just using libicu to implement the concrete subclass and providing a few wrappers.  You can test for correctness quite easily by disabling the GS special cases and checking the test suite.  

I finally got around to tests this and commented out most of the subclass methods in GSString (apart from the length and characterAtIndex: and a few that where raising an exception in an intermediate class, plus one deprecated, which gets delegated from the abstract class to the concrete one). Even with all these missing the test, extended with our additional test code, worked correctly on my machine. Maybe you could give me an additional hint where you see the unicode bugs?

Fred


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Linux/Clang/Libobjc2 failure part 2 (ng)

David Chisnall-7
Hi Fred,

Sorry for the late reply:

On 1 Jul 2018, at 22:39, Fred Kiefer <[hidden email]> wrote:
>
> I finally got around to tests this and commented out most of the subclass methods in GSString (apart from the length and characterAtIndex: and a few that where raising an exception in an intermediate class, plus one deprecated, which gets delegated from the abstract class to the concrete one). Even with all these missing the test, extended with our additional test code, worked correctly on my machine. Maybe you could give me an additional hint where you see the unicode bugs?

I found that there was some inconsistent handling of -rangeOfComposedCharacterSequenceAtIndex: between NSString and GSString that were causing failures when the NSConstantString implementation was using the NSString version.  Looking at the code in the newabi branch of -base, where I was experimenting with using ICU for this, I think that’s the thing that was at the root of all of the test failures that I was seeing.

This method is slightly complicated by the fact that Cocoa and the unicode standard disagree on whether CR LF is a single composed character (Cocoa says no, unicode says yes).  

David


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Linux/Clang/Libobjc2 failure part 2 (ng)

Fred Kiefer

> Am 07.07.2018 um 13:14 schrieb David Chisnall <[hidden email]>:
>
> On 1 Jul 2018, at 22:39, Fred Kiefer <[hidden email]> wrote:
>>
>> I finally got around to tests this and commented out most of the subclass methods in GSString (apart from the length and characterAtIndex: and a few that where raising an exception in an intermediate class, plus one deprecated, which gets delegated from the abstract class to the concrete one). Even with all these missing the test, extended with our additional test code, worked correctly on my machine. Maybe you could give me an additional hint where you see the unicode bugs?
>
> I found that there was some inconsistent handling of -rangeOfComposedCharacterSequenceAtIndex: between NSString and GSString that were causing failures when the NSConstantString implementation was using the NSString version.  Looking at the code in the newabi branch of -base, where I was experimenting with using ICU for this, I think that’s the thing that was at the root of all of the test failures that I was seeing.

Yes, this was the case but on the 9th of April Richard brought these two implementations of this method on the same level. Now we either have a bug in both or in non of them :-)

Could we agree that now the subclassing of NSString should be correct? There surely is room to improve the whole class cluster, but no immediate need to do so.

Cheers,
Fred
_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Linux/Clang/Libobjc2 failure part 2 (ng)

Josh Freeman
In reply to this post by Riccardo Mottola-5
Hi Riccardo,

On Jun 24, 2018, at 4:28 PM, Riccardo Mottola wrote:

> On 24/06/2018 11:17, David Chisnall wrote:
>> This might be the issue with the Linux run-time linker’s failure to  
>> merge the ivar guess variables.  Can you try with this patch?
>>
>> http://lists.gnu.org/archive/html/discuss-gnustep/2017-12/msg00129.html
>>
>> This isn’t needed with the v2 ABI, but I need help fixing the  
>> issues with GNUstep’s NSString implementation before I can  
>> recommend enabling that for GNUstep, because the new  
>> NSConstantString representation exposes a lot of bugs in -base’s  
>> unicode string handling.
>
> The patch doesn't apply clean anymore, the code looks changed enough!


    If you still want to try this patch, you'll need to use an older  
version of libobjc2, from before the ivar code changes were checked in.

    Attached is an updated version of the install script - it now  
rolls back the checked-out libobjc2 sources to 2017-12-19 (shortly  
before the ivar code changed).

    The patch itself is also attached (unchanged from before). The  
install script expects to find the patch in the same directory as the  
script itself.

Cheers,

Josh






_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

install_gnustep_clang_with-libobc2-offsets-fix.sh (4K) Download Attachment
libobjc2_ivar_offsets_mismatch_fix.diff (1K) Download Attachment