bug#21509: 25.0.50; X11 error: BadPixmap when creating first emacsclient frame; and memory leak

[Dima Kogan]

martin rudalics <rudalics@gmx.at> writes:

> Now everything is much much clearer to me.  In fact, your plots make it
> easy to distinguish the "upfront" consumption from the actual leaks and
> allow to see the leakage clearly.  I'll eventually have to include links
> to your plots in the code.

Glad that was cleared up.


>  > Does any of this speak to you?
>
> The only thing that still stupefies me is why an 80k cons threshold
> eventually produces strictly more leakage than the 800k and 8000k ones.
> Do you have an explanation for that?
>
> Doesn't that also mean that with such a low threshold running the test
> for some twenty minutes will have us run out of memory?

Sigh. This was my fault: it appears that I sent you the wrong plot.
Apparently if the emacs windows pop up in the background, the toolkits
do less work and allocate less memory. The plot I sent by mistake was
made while I was doing other work on that machine, so the memory usage
is inconsistent. Yesterday I reran the trials to get good data, and the
data in that email is correct. But I sent the wrong plot by mistake.


> Ah yes.  Could you please run GTK (not the crashing one) with the 80k
> and 8000k cons thresholds too?

OK. Let's forget about yesterday's plot. Here's a new plot containing
all the correct data from yesterday, and these two new trials you just
asked for.

In both the lucid and gtk cases, we get similar results with
gc-cons-threshold=80k and gc-cons-threshold=800k.

Setting it to 8000k, we observe an initial steep climb of ~8000k, at
which point the gc kicks in, and we start leaking at the same rate as
the 80k,800k cases, albeit with a ~8000k offset. I think the initial
climb makes sense to me, but not the offset. Does it make sense to you?

emacs21509_2017-10-15.pdf
Description: Adobe PDF document

gtk.yes.refcount.logic.gc80k.log
Description: Binary data

gtk.yes.refcount.logic.gc8000k.log
Description: Binary data