Opened 12 years ago

Closed 10 years ago

#2851 closed bug (fixed)

[Terminal] resizing terminal window could crash it

Reported by: diver Owned by: bonefish
Priority: normal Milestone: R1
Component: Applications/Terminal Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All


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

Attachments (2)

term_resize.png (81.3 KB ) - added by diver 12 years ago.
backtrace.png (86.6 KB ) - added by diver 11 years ago.

Download all attachments as: .zip

Change History (19)

by diver, 12 years ago

Attachment: term_resize.png added

comment:1 by diver, 12 years ago

Summary: [Terminal] resizing terminal window coult crash it[Terminal] resizing terminal window could crash it

comment:2 by axeld, 11 years ago

Owner: changed from jackburton to bonefish

comment:3 by bonefish, 11 years ago

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.

comment:4 by diver, 11 years ago

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.

comment:5 by diver, 11 years ago

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

comment:6 by diver, 11 years ago

running cat /dev/random will crash it much faster

by diver, 11 years ago

Attachment: backtrace.png added

comment:7 by diver, 11 years ago

Added another backtrace, one more bug?

comment:8 by diver, 10 years ago

Still here in hrev35569.

comment:9 by bonefish, 10 years ago

Version: R1/pre-alpha1R1/Development

comment:10 by bonefish, 10 years ago

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.

comment:11 by diver, 10 years ago

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

comment:12 by anevilyak, 10 years ago

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.

comment:13 by diver, 10 years ago

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

comment:14 by diver, 10 years ago

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

comment:15 by bonefish, 10 years ago

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.

comment:16 by bonefish, 10 years ago

Status: newin-progress

comment:17 by bonefish, 10 years ago

Resolution: fixed
Status: in-progressclosed

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.

Note: See TracTickets for help on using tickets.