Hi, Riccardo! > On Jan 24, 2020, at 00:51, Riccardo Mottola <riccardo.mott...@libero.it> > 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