Nicholas Marriott <nicholas.marri...@gmail.com> writes: > Do you have this change?
I was the one who reported this particular issue in the first place. And the reason I'm using Valgrind now is that even after this change, tmux seems to leak. Example report of a few seconds of resizing my terminal: ==19895== HEAP SUMMARY: ==19895== in use at exit: 1,272,566 bytes in 2,811 blocks ==19895== total heap usage: 2,161,482 allocs, 2,158,671 frees, 13,180,528,775 bytes allocated ==19895== ==19895== 1,540 bytes in 1 blocks are possibly lost in loss record 173 of 197 ==19895== at 0x4C2C47E: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==19895== by 0x451094: xrealloc (xmalloc.c:79) ==19895== by 0x41DECF: grid_reflow_join (grid.c:488) ==19895== by 0x41E216: grid_reflow (grid.c:589) ==19895== by 0x42F084: screen_reflow (screen.c:371) ==19895== by 0x42EA6B: screen_resize (screen.c:146) ==19895== by 0x4500C2: window_pane_resize (window.c:857) ==19895== by 0x425319: layout_fix_panes (layout.c:217) ==19895== by 0x4259F0: layout_resize (layout.c:443) ==19895== by 0x42AC98: recalculate_sizes (resize.c:127) ==19895== by 0x430FAF: server_client_msg_dispatch (server-client.c:759) ==19895== by 0x42FA5F: server_client_callback (server-client.c:221) ==19895== ==19895== 25,214 bytes in 53 blocks are definitely lost in loss record 193 of 197 ==19895== at 0x4C2C26B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==19895== by 0x450FE7: xmalloc (xmalloc.c:63) ==19895== by 0x41E023: grid_reflow_split (grid.c:527) ==19895== by 0x41DF72: grid_reflow_join (grid.c:501) ==19895== by 0x41E216: grid_reflow (grid.c:589) ==19895== by 0x42F084: screen_reflow (screen.c:371) ==19895== by 0x42EA6B: screen_resize (screen.c:146) ==19895== by 0x4500C2: window_pane_resize (window.c:857) ==19895== by 0x425319: layout_fix_panes (layout.c:217) ==19895== by 0x4259F0: layout_resize (layout.c:443) ==19895== by 0x42AC98: recalculate_sizes (resize.c:127) ==19895== by 0x430FAF: server_client_msg_dispatch (server-client.c:759) ==19895== ==19895== 127,862 bytes in 481 blocks are definitely lost in loss record 196 of 197 ==19895== at 0x4C2C47E: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==19895== by 0x451094: xrealloc (xmalloc.c:79) ==19895== by 0x41D2C3: grid_expand_line (grid.c:227) ==19895== by 0x41D489: grid_set_cell (grid.c:264) ==19895== by 0x41C550: grid_view_set_cell (grid-view.c:52) ==19895== by 0x42E2C5: screen_write_cell (screen-write.c:1125) ==19895== by 0x41EF25: input_print (input.c:883) ==19895== by 0x41EBB3: input_parse (input.c:781) ==19895== by 0x44FF86: window_pane_read_callback (window.c:820) ==19895== by 0x549C4BC: ??? (in /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5.1.7) ==19895== by 0x5491CCB: event_base_loop (in /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5.1.7) ==19895== by 0x433B7D: server_loop (server.c:204) ==19895== ==19895== 878,808 bytes in 1,081 blocks are definitely lost in loss record 197 of 197 ==19895== at 0x4C2C47E: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==19895== by 0x451094: xrealloc (xmalloc.c:79) ==19895== by 0x41DECF: grid_reflow_join (grid.c:488) ==19895== by 0x41E216: grid_reflow (grid.c:589) ==19895== by 0x42F084: screen_reflow (screen.c:371) ==19895== by 0x42EA6B: screen_resize (screen.c:146) ==19895== by 0x4500C2: window_pane_resize (window.c:857) ==19895== by 0x425319: layout_fix_panes (layout.c:217) ==19895== by 0x4259F0: layout_resize (layout.c:443) ==19895== by 0x42AC98: recalculate_sizes (resize.c:127) ==19895== by 0x430FAF: server_client_msg_dispatch (server-client.c:759) ==19895== by 0x42FA5F: server_client_callback (server-client.c:221) ==19895== ==19895== LEAK SUMMARY: ==19895== definitely lost: 1,031,884 bytes in 1,615 blocks ==19895== indirectly lost: 0 bytes in 0 blocks ==19895== possibly lost: 1,540 bytes in 1 blocks ==19895== still reachable: 239,142 bytes in 1,195 blocks ==19895== suppressed: 0 bytes in 0 blocks (Also, I suspect that avoiding 13GB worth of allocations would speed things up considerably...) ------------------------------------------------------------------------------ The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
