Re: crash when using local display but not remote

[Bertrand Dekoninck]

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 ?)
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