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

[Dima Kogan <dima@secretsauce.net>]

martin rudalics <rudalics@gmx.at> writes:

>  > 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".

No, that's not right.

Lucid with scrollbars post-fix is the blue line: memory usage is stable
as frames are created/destroyed: the leak is ~0

Lucid without scrollbars pre-fix is the green line. Memory usage is
climbing. We aren't leaking as badly as the other cases, but we ARE
leaking.

So the fix resolved the large leakages in the other cases and also the
small leakages that weren't scroll-bar-related.


> 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.

I don't think this is right either. Lucid with scrollbars pre-fix is the
purple line. We leak memory at a high, constant rate. GTK memory usage
(yellow) is noisy and fragmented (I bet we're invoking malloc/free much
more often). The baseline memory consumption is higher, the past that,
the leak rate isn't nearly as bad as the purple. The higher
fragmentation means that the internals of malloc() matter too: I invoked
malloc_trim() just after t=450s, and we see the memory usage dropped
sharply as a result.


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

I haven't run that experiment, but I could do that. Probably won't get
to it for a week, though.


> 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.

OK. I'll look.

By the way, if you haven't tried it yet, look at rr:

http://www.rr-project.com

It's a debugging instrumentation tool that saves a process execution
trace, and lets you replay it forwards and backwards in gdb. Could make
it possible to find heisen-problems such as this.