[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: crash when using local display but not remote

From: Fred Kiefer
Subject: Re: crash when using local display but not remote
Date: Tue, 18 Feb 2020 08:37:59 +0100

> 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/
> (gdb) bt
> #0  0x2b898a94 in kill () from /lib/
> #1  0x2b674b88 in pthread_kill () from /lib/
> #2  0x2b674c00 in raise () from /lib/
> #3  0x2b89a190 in abort () from /lib/
> #4  0x2b8d6294 in __fsetlocking () from /lib/
> #5  0x2b8d6294 in __fsetlocking () from /lib/
> Previous frame identical to this frame (corrupt stack?)

This does not really help.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]