[Terminal] resizing terminal window could crash it

[diver]

I tried to resize terminal wile I was connected via ssh to my freebsd server and running mc and got a crash.

[bonefish]

I've tried to reproduce this by frantically resizing the window in various situations (with/without lots of output, with primary/alternative screen buffer, etc.). Without success.

[diver]

I can reproduce it in hrev32034.
For this I have to ssh to ubuntu and run midnight commander
I have to resize terminal several times (20 times or more) to crash it.

[diver]

ProcessController still show that ssh connection, is it on purpose, or I should open another bug?

[diver]

running cat /dev/random will crash it much faster

[diver]

Added another backtrace, one more bug?

[diver]

Still here in hrev35569.

[bonefish]

Still cannot reproduce this bug. The only thing "cat /dev/random" does for me is deadlocking the terminal eventually. Which is kind of expected since the "EscParse" thread writes to the tty. There's no simple way around this, though.

Any more specific instructions how you reproduce the problem?

Regarding the second stack trace, this looks like an interface kit problem and I seem to recall that graphics state related bugs have been fixed not that long ago. If you encounter it again, please open a new ticket.

[diver]

I just reproduced it like this:
Opened Terminal.
Typed find.
Resized Terminal several times to it's minimum and back.

[anevilyak]

Is this in VirtualBox or real hardware or what? I've been trying this for the past 5 minutes with hrev35580 and I haven't succeeded in crashing it once.

[diver]

This is VirtualBox. You just need to resize Terminal really fast and it will crash within several seconds.

[diver]

I can't reproduce it on real hw too, only inside VirtualBox.

[bonefish]

When testing in qemu without kernel acceleration (i.e. no --enable-kvm) I can reproduce resize crashes easily (both with "cat /dev/random" and "while true; do find /; done"), too. So far I've only seen two versions of BView::PopState() stack traces (one like the attached one), though.

[bonefish]

At least the problems I could reproduce are fixed in hrev35587. I've never seen the original stack trace, but quite a few things have been fixed since the bug was reported. So I assume that issue doesn't exist anymore.