Re: crash when using local display but not remote

[Sergii Stoian]

Hi Bertrand,

> On Jan 26, 2020, at 02:09, Bertrand Dekoninck <address@hidden> wrote:
> 
> Hi Riccardo !
> I’ve installed art on debian buster x64 with the gnustep runtime (2.0) from 
> latest source on github.com/gnustep (does it answer your PS, Sergii ?)

It depends on what version of Debian installed on Riccardo's MIPS machine...

> I did’n’t try Ink, but Gworkspace works fine (well not its inspectors, of 
> course) locally. I don’t see your error, Ricardo. Has this error something to 
> do with the "Sync extension «  not present on your system xlib ?
> 
> What should I do with valgrind ?
> 
> Bertrand
> 
>> Le 25 janv. 2020 à 00:13, cobjective <address@hidden> a écrit :
>> 
>> Hi, Riccardo!
>> 
>>> On Jan 24, 2020, at 00:51, Riccardo Mottola <address@hidden> wrote:
>>> 
>>> Hi!
>>> 
>>> to test the latest "libart" stuff I upgraded all GNUStep on the old and 
>>> venerable MIPS Book Letux400
>>> 
>>> I got everything to build! yeah!
>>> 
>>> If I export the display through ssh, everything works and (albeit slow... 
>>> the Letux had the LAN connected through USB on the board) I get a fine 
>>> looking GNUstep!
>>> 
>>> If I use it locally, however, I get an immediate crash:
>>> 
>>> (gdb) r
>>> Starting program: /home/usr-GNUstep/Local/Tools/Ink
>>> [Thread debugging using libthread_db enabled]
>>> [New Thread 16384 (LWP 330)]
>>> Xlib:  extension "SYNC" missing on display ":0.0".
>>> *** glibc detected *** double free or corruption (out): 0x00636300 ***
>>> 
>>> Program received signal SIGABRT, Aborted.
>>> [Switching to Thread 16384 (LWP 330)]
>>> 0x2b898a94 in kill () from /lib/libc.so.6
>>> (gdb) bt
>>> #0  0x2b898a94 in kill () from /lib/libc.so.6
>>> #1  0x2b674b88 in pthread_kill () from /lib/libpthread.so.0
>>> #2  0x2b674c00 in raise () from /lib/libpthread.so.0
>>> #3  0x2b89a190 in abort () from /lib/libc.so.6
>>> #4  0x2b8d6294 in __fsetlocking () from /lib/libc.so.6
>>> #5  0x2b8d6294 in __fsetlocking () from /lib/libc.so.6
>>> Previous frame identical to this frame (corrupt stack?)
>>> 
>>> this does not look very useful and looks like very early memory corruption?
>>> 
>>> I recompiled all back with debug=yes, I hope that still disables 
>>> optimizations correctl. I do not get a better stack. and not a better 
>>> outcome either!
>>> 
>>> Could someone using art on x86 or amd64 try valgrind?
>>> 
>> 
>> 
>> Give more information, please.
>> Why do you think it’s art backend? Did you try other 
>> backends/compiler/linker?
>> What are your build options (runtime, library combo, compiler, linker)?
>> 
>> P.S.: Does it mean you can build art backend without ftfont-old.m (with my 
>> changes to art)?
>> 
>> Sergii
>