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

[martin rudalics <rudalics@gmx.at>]

 > So in the case of lucid widgets, you not only fixed the bug,

I coin it a "fix" because I just pushed the same workaround that had
been used for the GTK build before.  But it hardly qualifies as a real
fix because it makes the referencing counting mechanism practically
obsolete for any kind of frame deletion.

 > but also
 > massively plugged the memory leaks that were associated with new emacs
 > frames. Awesome!

IIUC your numbers of Lucid with scrollbars now coincide with the numbers
of Lucid without scrollbars before the "fix".  OTOH the numbers for GTK
largely coincide with those of Lucid with scrollbars before the "fix".
So X itself seems much more dominant than any toolkit particularities.

 > The fix doesn't affect GTK, so that plot is just for reference. It's
 > clearly still leaking, and its baseline memory usage is higher. I was
 > thinking that GTK does a larger number of small allocations that are
 > soon freed, and thus suffers from more fragmentation issues. To test
 > that, I invoked malloc_trim(0) just after t=450 in the gtk run. This
 > asks malloc to return the the kernel all the unused memory it's holding.
 > And we see a 5MB drop. So the GTK leaks aren't as bad as they look.

I think what was going on before the "fix" is this: We free data we
shouldn't, probably due to a bug in the reference counting mechanism.
Some time later, after that data got overwritten, the new data triggers
the error in the toolkit code.  I say "some time later" because the
error (1) apparently nowhere triggers with _every_ invocation of
emacsclient, (2) its frequency seems to differ according to the various
bug reports from every third invocation to every fifth, and (3) it seems
to have a fairly constant frequency, at least here when it starts to
happen every third invocation it will continue to happen every third
invocation.

While the above tries to explain the bug reported by the toolkit, any
memory leak should follow from trying to delete the terminal but when
doing so we forget to explicitly free some (maybe font related) data and
when invoking a new client we reallocate that data instead of reusing
the one we forgot about.

This does not explain any difference between the GTK (before the "fix")
and Lucid (after the "fix") behaviors.  What happens with GTK when you
allow it to delete the terminal by allowing terminal->reference_count
drop to zero?  If it does not crash immediately, is the memory leak more
heavy than it is now?

Also, could you try whether changing ‘gc-cons-threshold’ in either
direction has any impact on the occurrence of the toolkit bug or the
growth of the memory leak?  Once I thought that this could affect the
frequency of the error but didn't get any conclusive results.

Thanks, martin