Windows console size freezes after repeated resizing. about pdcurses HOT 8 CLOSED

Some more info. I built with WIDE=Y.
Bill's pdcurses version does not seem to freeze the console size.

from pdcurses.

So far, I can't reproduce this. Can you narrow it down to a more specific series of actions?

What's the exact version of Windows (e.g. 1809 or 1903 -- Settings > System > About > Version)?

from pdcurses.

I'm running Windows 10 Pro, 64 bit, Dutch, version 1803.
I used gcc 6.2.0, mingw-w64 64 bit.
Windows Console property "legacy mode" disabled.
Windows Console property Layout >> "Wrap text output on resize" enabled.

I noticed this behaviour first with pdcurses 3.7, which freezes quite fast (usually less than 10 resizes are needed). With version 3.8 it takes more resizes. I'm now testing the latest pdcurses from git. I grab the bottom edge of the windows console and start moving the bottom edge continuously up and down. It can take up to 50 up and down moves.

With Bill's version I tried up to more than 200 moves, and it doesn't freeze.

from pdcurses.

BTW, I was actually surprised by how well this worked when I tried it. It's never been that hard to crash the demos by resizing -- none of them were written with it in mind, and only half of them have been quasi-adapted.

After I couldn't make it happen in wincon, for the heck of it I went back to my Mac and tried sdl2, x11 and x11new. I only got rain to crash once, in x11, and not again. But I don't really know whether that was the same problem as you're seeing.

I noticed this behaviour first with pdcurses 3.7, which freezes quite fast (usually less than 10 resizes are needed). With version 3.8 it takes more resizes.

There's literally no difference in the relevant source code between 3.7 and 3.8. I suppose there could still be differences due to compilation artifacts...

It can take up to 50 up and down moves.

If that's what it takes to reproduce this, then I'm sorry, but it's kind of hard to take it seriously.

With Bill's version I tried up to more than 200 moves, and it doesn't freeze.

I'd be very surprised if there are really any differences in that version that make it resize better (and I'm pretty sure none intentionally do so), but I'd be interested if you can dig one up.

from pdcurses.

I just tried it over 150 cycles without a freeze. (I did see some other issues -- a scroll bar sometimes appearing, and the horizontal size seeming to fluctuate while I was only resizing vertically -- see #42 for what I suspect is a related issue.)

I'm using GCC 8.1, though.

from pdcurses.

I am reasonably sure that the only work done on my fork to support Wincon resizing was a shameless copy of William's work, committed in mine on 2018 Jan 12. Which suggests to me that if you try William's fork from that date, it too might resize properly; bisection could then tell you when the bug got introduced.
I see various resizing issues, but I'm running Wineconsole on a Linux box; I've always seen resizing problems with Wincon on that platform. Don't recall any problems on "real" Windows, but haven't tried it for a while.

from pdcurses.

If there's a bug, I doubt it's recent. It'll be some ancient off-by-one error in memory allocation or access, that only has any effect under exactly the wrong conditions -- hence the difference depending on the compiler, or on irrelevant code changes far from anything to do with resizing.

from pdcurses.

I tried gcc 9.1.0 and it makes no difference. Same behaviour.

The freeze happens each time after a different number of resizes. Sometimes a few, sometimes a lot. I understand this is hard to debug. It could be a leak somewhere else in the library. I have no time to debug this myself. I'm not familiar with the pdcurses code, and have no time to learn it.

For my next wcd release the resizing support in wincon (and ConEmu), on 'real' Windows, is an important new feature. Therefore I was stressing the resizing beyond normal use. I think that pdcurses 3.8 is stable enough for normal use, so I will go for that.

PS
I did not see any issues in ConEmu. ConEmu works differently. It triggers the resize event when you release the mouse button. So ConEmu triggers a lot less resizes. Windows console triggers resize events with every change of the console size, provided that you have the wincon property Layout >> "Wrap text output on resize" enabled. In Wincon you see the application adapting to the console size while you are dragging an edge, in ConEmu only after you release the edge. The rain application is not a good demo to see this, because the application output is changing all the time. With stable output you can see it.

from pdcurses.