Re: crash when using local display but not remote

[Fred Kiefer]

> Am 17.02.2020 um 23:53 schrieb Riccardo Mottola <address@hidden>:
> 
> Fred Kiefer wrote:
>> 
>> 
>> With all the latest changes could you please try again and report the stack 
>> trace you are getting? It would also help if you could find out which code 
>> is crashing. For this you could start by getting the normal debug output 
>> from the backend (—GNU-Debug=Dflt,XGTrace,Frame) and after you have the 
>> general region just add a few NSLog statements of your own.
> 
> How do you exactly use that? I tried both:
> 
> defaults write GNU-Debug {Dflt,XGTrace,Frame}
> 
> as well as:
> 
> Ink --GNU-Debug=Dflt,XGTrace,Frame


You may have to set these separately. I was hoping there was a way to specify 
and array here, but did not check. So the easiest was is

Ink —GNU-Debug=Dflt —GNU-Debug=XGTrace —GNU-Debug=Frame

>> The original message you posted (glibc detected *** double free or 
>> corruption (out)) points to a free call. We have plenty of these, but this 
>> might be a hint when you are getting closer.
> 
> I hope so. building with "debug=yes" and running in gdb makes an
> incredible slow run, but no better trace:
> 
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 16384 (LWP 12897)]
> 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 really help.