Opened 11 years ago

Closed 9 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:
Has a Patch: no Platform: All

Description

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 11 years ago.
backtrace.png (86.6 KB) - added by diver 10 years ago.

Download all attachments as: .zip

Change History (19)

Changed 11 years ago by diver

Attachment: term_resize.png added

comment:1 Changed 11 years ago by diver

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

comment:2 Changed 10 years ago by axeld

Owner: changed from jackburton to bonefish

comment:3 Changed 10 years ago by 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.

comment:4 Changed 10 years ago by 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.

comment:5 Changed 10 years ago by diver

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

comment:6 Changed 10 years ago by diver

running cat /dev/random will crash it much faster

Changed 10 years ago by diver

Attachment: backtrace.png added

comment:7 Changed 10 years ago by diver

Added another backtrace, one more bug?

comment:8 Changed 9 years ago by diver

Still here in hrev35569.

comment:9 Changed 9 years ago by bonefish

Version: R1/pre-alpha1R1/Development

comment:10 Changed 9 years ago by 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.

comment:11 Changed 9 years ago by diver

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

comment:12 Changed 9 years ago by 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.

comment:13 Changed 9 years ago by diver

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

comment:14 Changed 9 years ago by diver

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

comment:15 Changed 9 years ago by 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.

comment:16 Changed 9 years ago by bonefish

Status: newin-progress

comment:17 Changed 9 years ago by bonefish

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.