Re: crash when using local display but not remote

[cobjective]

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