pixel plots blow up upon reaching the far side

[dankamongmen]

whoops! running an experimental notcurses-demo with NCBLIT_PIXEL on a 40-cell-wide plot, we blew up in the middle of fission. interestingly, it wasn't a SIGSEGV or anything of that nature, but rather a SIGKILL, suggesting the OOM handler chose to throw us out of the plane. this might then have been a memory leak, and might have been resolved by very late work in the 2.3.x cycle on plots (this happened a few days before release--i forgot to file a bug then). Determine whether this is still a problem, and fix it if so.

[dankamongmen]

so i ran a few valgrinds over intro + xray, and saw no memory lost. with that said, i think we use ncpile_destroy() in shutdown, which is going to kill all planes. that doesn't mean we're not holding onto a crapton of them. and indeed, the 13.1GB RES of my currently-running notcurses-demo suggests a false hold. let's SIGSEGV it externally and get a peak.

[dankamongmen]

ahh, switching the fbuf implementation from mmap to malloc quickly reveals the leak:

==3936175== 69,206,016 bytes in 33 blocks are definitely lost in loss record 283 of 283
==3936175==    at 0x48397B5: malloc (vg_replace_malloc.c:380)
==3936175==    by 0x4A286E2: fbuf_initgrow (fbuf.h:116)
==3936175==    by 0x4A286E2: fbuf_init (fbuf.h:141)
==3936175==    by 0x4A286E2: sprixel_alloc (sprite.c:127)
==3936175==    by 0x4A30898: ncvisual_render_pixels (visual.c:1021)
==3936175==    by 0x4A30F94: ncvisual_render (visual.c:1096)
==3936175==    by 0x4A150B9: redraw_pixelplot_uint64_t (plot.c:566)
==3936175==    by 0x4A16175: redraw_plot_uint64_t (plot.c:566)
==3936175==    by 0x11781E: demo_render.part.0 (hud.c:592)
==3936175==    by 0x118667: demo_render (hud.c:537)
==3936175==    by 0x118667: demo_nanosleep_abstime_ns (hud.c:547)
==3936175==    by 0x119129: demo_nanosleep (hud.c:563)
==3936175==    by 0x11A381: intro (intro.c:244)
==3936175==    by 0x1103A3: ext_demos (demo.c:224)
==3936175==    by 0x1103A3: main (demo.c:560)

whoops!

[dankamongmen]

we definitely kill that in sprixel_free() which the logs do seem to show us hitting...

[dankamongmen]

[schwarzgerat](0) $ grep Destroying\ sprix e  | wc -l
120
[schwarzgerat](0) $ grep 'Phase 1' e | sort | cut -d\  -f4 | uniq  | wc -l
120
[schwarzgerat](0) $ 

odd.

[dankamongmen]

so perhaps something is changing ->glyph while they're alive?

[dankamongmen]

got it