pdcscrn.c - PDC_scr_free about pdcurses

[wmcbrine]

You might want to elaborate... but I do see where there might be an issue with the existing code, in the (rare!) case where someone calls delscreen(), and then exits, under X11. (If it's a different situation that you're encounternig, please tell me.)

[Bill-Gray]

I think he's trying to avoid a re-free. Better way to do this might be to replace

    if (icon_pixmap)
        XFreePixmap(XCURSESDISPLAY, icon_pixmap);
    if (icon_pixmap_mask)
        XFreePixmap(XCURSESDISPLAY, icon_pixmap_mask);

with

    if (icon_pixmap)
    {
        XFreePixmap(XCURSESDISPLAY, icon_pixmap);
        icon_pixmap = NULL;
    }
    if (icon_pixmap_mask)
    {
        XFreePixmap(XCURSESDISPLAY, icon_pixmap_mask);
        icon_pixmap_mask = NULL;
    }

...i.e., if you free something, set it to NULL so you won't try to free it again.
I vaguely recall running into such issues when using Valgrind to search for memory leaks. As I recall, I got some example code using the VT, WinGui, and I think one other flavor to free all the memory that had been allocated. I couldn't get the X11 flavor to close that cleanly, but didn't really try all that hard. ncurses left lots of memory allocated; apparently, that's a known, won't-fix problem.
The above double-free situation may seem like a 'rare' case. But I do have code that uses

   endwin( );
   getch( );
   initscr( );       /* and further Curses initialization */

so that I can (in ncurses and the VT and WinCon flavors of PDCurses) temporarily show what was on the console before Curses or PDCurses were started.

[rexx-org]

Further to this I get a double free on exiting THE. This is because THE calls XCursesExit() explicitly (because that was the way you had to do it) which calls PDC_scr_free(), and now PDCurses calls PDC_scr_free() atexit the double free occurs.
XCursesExit() should do nothing now.

[Bill-Gray]

Mark, I've implemented the solution proposed above for my fork. Does this do the trick for you?
If delscreen(SP) is called, Valgrind finds only one memory leak in the X11 version, from XtVaGetApplicationResources(). I don't know enough about X to know what's going on there or what to do about it.
For SDL1 and SDL2, lots of memory is allocated and never freed. In theory, I can do similar testing for WinCon and WinGUI by running them under Wine through Valgrind, but thus far, I've been unable to get that to work. The VT port appears to be properly freeing everything it allocates.

[rexx-org]

Bill. The link you provide is not to the x11/pdcscrn.c. Besides I am not calling delscreen(), I am calling XCursesExit() only for the x11 build of THE.

[Bill-Gray]

(Groan) Sorry, here's the correct link. I kinda confused things by mentioning delscreen(SP) and XtVaGetApplicationResources(); those are both memory leak issues, not double-frees. The pdcscrn.c for X11 that I've posted just addresses the double-free issue you describe, and does so with the common rubric

if( pointer != NULL)   /* don't try freeing it again if it's already been */
{                      /* freed,  or was never alloced in the first place */
    free( pointer);
    pointer = NULL;
}

(repeated several times within my revised PDC_scr_free() for each of the various quantities that that function is expected to free up.)

[rexx-org]

Hi Bill. Yes that works well for me. Thanks.