[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: Riccardo Mottola
Subject: Re: crash when using local display but not remote
Date: Mon, 17 Feb 2020 23:53:29 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/

Hi Fred,

Fred Kiefer wrote:
> It is rather the later and that would also only change for the application 
> icon. We should instead concentrate on the crash you are having on the Letux. 
> You wrote that the version from  September 14th works fine. Does this version 
> also show the message „Xlib:  extension "SYNC" missing on display ":0.0“.“? 
> If it does we may ignore this hint, otherwise it might be worthwhile to 
> follow.

I extra checked once again by compiling the old version and installing it.
I get several messagies for the SYNC message (I think one for every
window at least) and everything works. So we should ignore that, at
least, for the crash it is invariant.

> 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

but nothing useful gets printed out, just the crash.

Do I need to recompile something with some specific option?

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


reply via email to

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