Re: gui apps segfault on Linux/x86/clang/libobjc2

[Fred Kiefer]

> Am 02.12.2018 um 15:21 schrieb Riccardo Mottola <riccardo.mottola@libero.it>:
> 
> I would rather not point the bug into xcb or X11, other non-gnustep apps do 
> work fine, including sensitive apps like Firefox and emacs.
> 
> Fred Kiefer wrote:
>> Both the reported issues should be rather harmless. For the one in back I 
>> already committed a fix to prevent it. Please try with the current version 
>> on git.
> 
> INdeed, updating back makes the error go away in valgrind (but... not the 
> segfault)
> 
>> I will look into the base issue as well, but expect that this is also not 
>> the cause of your problem. It is far more interesting that you get the 
>> segmentation fault only when not running with valgrind. Is the stack trace 
>> of the segmentation fault still the same?
> 
> "interesting" but what does it tell us? Valgrind is preventing some memory 
> damage: It is a matter of Heiseberg, trying to measure modifies the object of 
> measure! It may happen with gdb too, but not in this case.

Yes, but this means that we are not accessing an uninitialised value here, as 
otherwise valgrind would detect it and complain.

> ==9086== Source and destination overlap in memcpy(0x9e68c18, 0x9e68c18, 24)
> ==9086==    at 0x4035409: __GI_memcpy (in 
> /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
> ==9086==    by 0x4C1224C: 
> _i_GSFFIInvocation__initWithCallback_values_frame_signature_ (in 
> /System/Library/Libraries/libgnustep-base.so.1.25.1)
> ==9086==    by 0x4C1359A: GSFFIInvocationCallback (in 
> /System/Library/Libraries/libgnustep-base.so.1.25.1)
> ==9086==    by 0x7566A74: ??? (in /usr/lib/libffi.so.6.0.4)
> ==9086==    by 0x7566E25: ??? (in /usr/lib/libffi.so.6.0.4)
> ==9086==    by 0x4A776EA: _i_NSDistributedNotificationCenter_Private__connect 
> (in /System/Library/Libraries/libgnustep-base.so.1.25.1)
> ==9086==    by 0x4A75C22: 
> _i_NSDistributedNotificationCenter__addObserver_selector_name_object_suspensionBehavior_
>  (in /System/Library/Libraries/libgnustep-base.so.1.25.1)
> ==9086==    by 0x4A7592D: 
> _i_NSDistributedNotificationCenter__addObserver_selector_name_object_ (in 
> /System/Library/Libraries/libgnustep-base.so.1.25.1)
> ==9086==    by 0x4558336: _i__GSWorkspaceCenter__init (in 
> /System/Library/Libraries/libgnustep-gui.so.0.26.2)
> ==9086==    by 0x4AFACCA: _c_NSObject__new (in 
> /System/Library/Libraries/libgnustep-base.so.1.25.1)
> ==9086==    by 0x455A2C4: _i_NSWorkspace__init (in 
> /System/Library/Libraries/libgnustep-gui.so.0.26.2)
> ==9086==    by 0x455A06B: _c_NSWorkspace__sharedWorkspace (in 
> /System/Library/Libraries/libgnustep-gui.so.0.26.2)
> ==9086==
> 2018-12-02 15:06:56.370 Ink[9086:9086] Unable to contact pasteboard server - 
> please ensure that gpbs is running for local host.
> 2018-12-02 15:07:09.316 Ink[9086:9086] Unable to contact pasteboard server - 
> please ensure that gpbs is running for local host.
> ==9086==
> ==9086== HEAP SUMMARY:
> ==9086==     in use at exit: 7,056,137 bytes in 65,574 blocks
> ==9086==   total heap usage: 224,958 allocs, 159,384 frees, 24,190,943 bytes 
> allocated
> ==9086==
> ==9086== LEAK SUMMARY:
> ==9086==    definitely lost: 429,675 bytes in 9,125 blocks
> ==9086==    indirectly lost: 21,386 bytes in 1,258 blocks
> ==9086==      possibly lost: 1,589,835 bytes in 14,925 blocks
> ==9086==    still reachable: 5,015,241 bytes in 40,266 blocks
> ==9086==                       of which reachable via heuristic:
> ==9086==                         newarray           : 46,317 bytes in 1,466 
> blocks
> ==9086==         suppressed: 0 bytes in 0 blocks
> ==9086== Rerun with --leak-check=full to see details of leaked memory
> ==9086==
> ==9086== For counts of detected and suppressed errors, rerun with: -v
> ==9086== ERROR SUMMARY: 10 errors from 1 contexts (suppressed: 1 from 1)

As I wrote, I think that this is unrelated to your actual issue. As the problem 
doesn’t happen when running under valgrind, this tools is this time no big 
help. Although I will still suggest to use it as the first choice when ever you 
have a segmentation fault.


> Program received signal SIGSEGV, Segmentation fault.
> 0xb3ead101 in xcb_writev () from /usr/lib/libxcb.so.1
> (gdb) bt
> #0  0xb3ead101 in xcb_writev () from /usr/lib/libxcb.so.1
> #1  0xb40473ce in _XSend () from /usr/lib/libX11.so.6
> #2  0xb40479c1 in _XReply () from /usr/lib/libX11.so.6
> #3  0xb402d45e in XGetWindowProperty () from /usr/lib/libX11.so.6
> #4  0xb402c253 in XGetIconSizes () from /usr/lib/libX11.so.6
> #5  0xb4438452 in -[XGServer(WindowOps) iconSize] () from 
> /System/Library/Bundles/libgnustep-back-026.bundle/libgnustep-back-026
> #6  0xb7d418fe in GSGetIconSize () from 
> /System/Library/Libraries/libgnustep-gui.so.0.26
> #7  0xb7a56380 in +[NSAppIconView initialize] () from 
> /System/Library/Libraries/libgnustep-gui.so.0.26
> #8  0xb714015c in objc_send_initialize () from 
> /System/Library/Libraries/libobjc.so.4.6
> #9  0xb714c4d8 in slowMsgLookup () from 
> /System/Library/Libraries/libobjc.so.4.6
> #10 0xb71525e1 in objc_msgSend () from 
> /System/Library/Libraries/libobjc.so.4.6
> #11 0xb7a626cd in -[NSApplication(Private) _appIconInit] () from 
> /System/Library/Libraries/libgnustep-gui.so.0.26
> #12 0xb7a58041 in -[NSApplication _init] () from 
> /System/Library/Libraries/libgnustep-gui.so.0.26
> #13 0xb7455232 in -[NSObject performSelector:withObject:] () from 
> /System/Library/Libraries/libgnustep-base.so.1.25
> #14 0xb74eb675 in -[NSObject(NSThreadPerformAdditions) 
> performSelector:onThread:withObject:waitUntilDone:modes:] ()
>   from /System/Library/Libraries/libgnustep-base.so.1.25
> #15 0xb74eb2ec in -[NSObject(NSThreadPerformAdditions) 
> performSelectorOnMainThread:withObject:waitUntilDone:modes:] ()
>   from /System/Library/Libraries/libgnustep-base.so.1.25
> #16 0xb74eb391 in -[NSObject(NSThreadPerformAdditions) 
> performSelectorOnMainThread:withObject:waitUntilDone:] ()
>   from /System/Library/Libraries/libgnustep-base.so.1.25
> #17 0xb7a58420 in -[NSApplication init] () from 
> /System/Library/Libraries/libgnustep-gui.so.0.26
> #18 0xb7a57bbf in +[NSApplication sharedApplication] () from 
> /System/Library/Libraries/libgnustep-gui.so.0.26
> #19 0xb7a2c6f2 in NSApplicationMain () from 
> /System/Library/Libraries/libgnustep-gui.so.0.26
> #20 0x0804ab52 in main ()

The only thing that could go wrong from out side in this X call are the 
parameters that we provide. What you could try to do is to log the X display 
variable „dpy“ right before this call. I do not see how this could happen but 
maybe this is still not initialised with a sensible value.