[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#21509: 25.0.50; X11 error: BadPixmap when creating first emacsclient
bug#21509: 25.0.50; X11 error: BadPixmap when creating first emacsclient frame; and memory leak
Sat, 09 Sep 2017 09:59:50 +0200
>> 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
> 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
>> 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:
> 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.