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

[martin rudalics]

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

I can't follow you.  before.no.scroll.log has

16112 19608 S ?        00:00:00 emacs
...
16112 29700 S ?        00:00:12 emacs

while after.yes.scroll.log has

17508 19652 S ?        00:00:00 emacs
...
17508 29160 S ?        00:00:13 emacs

which strike me as very similar (especially given the figures of the two
other logs).  What am I missing?

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

I can't tell that since it's not in your figures.  But again, the raw
data from before.log and after.yes.scroll.gtk.log seem similar too.

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

Please try.  If you succeed running it, the resulting difference between
the "before" GTK and Lucid runs should IMHO show the noise introduced by
malloc/free more clearly.  And obviously running the before/after
experiments for Motif would be interesting too: The Motif build crashed
in the menu bar section while the Lucid build crashed in the scroll bar
section.

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

http://www.rr-project.org

now.

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

If it's a GC related problem, it would need more patience than I'm able
to provide anyway.  I'm still trying to find a common pattern for all
these behaviors from a coarse-grained perspective.  And obviously it
would be interesting to find out why the whereabouts at the time of the
"X11 error that blows up the window" apparently differ for the various
builds.  IIUC it's still us who determine which one to draw first - the
menu bar or the scroll bar.

martin