Bug 176902 - Konsole: apps in tabbed shell truncated to 24 lines (LINES=24)
Summary: Konsole: apps in tabbed shell truncated to 24 lines (LINES=24)
Status: RESOLVED FIXED
Alias: None
Product: konsole
Classification: Unclassified
Component: general (show other bugs)
Version: 2.1
Platform: Fedora RPMs Linux
: NOR normal with 60 votes (vote)
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
: 199714 236405 244183 284523 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-12-04 17:50 UTC by sjalexandre
Modified: 2012-01-18 08:16 UTC (History)
20 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.8


Attachments
Flag to emit imageSizeChanged once (2.32 KB, patch)
2011-04-06 09:48 UTC, Martin von Gagern
Details
make sure pty device have proper size info (3.49 KB, patch)
2011-07-20 10:44 UTC, Jekyll Wu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sjalexandre 2008-12-04 17:50:50 UTC
Version:           2.1 (using KDE 4.1.3)
Compiler:          gcc-4.3.2-7.i386 
OS:                Linux
Installed from:    Fedora RPMs

When a new 80x40 konsole window is launched and a text file with more than 24 lines (for example /etc/passwd) is opened using vim, everything appears to work fine.  When a new tab is created in the same konsole window and the file is opened using vim, the vim content appears to be limited to 80x24 even though the window itself is still 80x40.

I was able to reproduce this issue using different user accounts and does not appear to be related to any environment settings.  Interestingly, when a new tab is created that displays this type of behaviour (where the vim content is truncated to 24 lines) is detached, the new window behaves normally (vim output is the full length of the window).

Also, this behaviour isn't limited to just the first tab, but to all subsequent tabs created after the initial window is launched.
Comment 1 sjalexandre 2008-12-05 18:12:45 UTC
As an update, when the entire window is resized say from 80x40 to 80x30 then back to 80x40, opening a text file in vim appears to work normally again.  
Comment 2 Jonathan Wakely 2009-01-06 21:41:14 UTC
i reported this to fedora bugzilla, with more detail and steps to reproduce:
https://bugzilla.redhat.com/show_bug.cgi?id=477359

resizing the window sends SIGWINCH to the shells which causes them to resize. It only happens when the window is initially 80x40, which seems weird to me.
Comment 3 Jonathan Wakely 2009-01-08 16:11:54 UTC
The title of this bug should be changed as it has nothing to do with vim, any app that uses the terminal's alternate screen buffer will use LINES=24.
e.g. man, less, info etc.
Comment 4 sjalexandre 2009-01-08 17:34:02 UTC
Jon, thanks for looking into this.  I agree based on your feedback the title of this bug should be changed, except it's not clear how to do this.  Is this something I can do or does an admin have to make the change?

Comment 5 Jonathan Wakely 2009-01-10 15:08:47 UTC
I'm not sure either, looks like this bugzilla is configured so it can't be changed. Maybe someone else with suitable privileges can do it. In any case there's enough ino here to reproduce it, so hopefully someone will find the problem.
Comment 6 Jonathan Wakely 2009-02-16 22:08:30 UTC
Can anyone confirm this, and change the title?

Still present with latest Fedora packages:
Konsole
Version 2.2
Using KDE 4.2.00 (KDE 4.2.0)
Comment 7 Jonathan Wakely 2009-06-05 16:37:14 UTC
Surely someone is capable of following the steps to reproduce and at least confirming this bug?

Here are my steps to reproduce, taken from https://bugzilla.redhat.com/show_bug.cgi?id=477359


1. Close all konsole windows
2. Open new konsole window, resize to 80x40, close window.
3. Open konsole window then open a new tab
4. In the new tab run 'echo $LINES ; resize ; echo $LINES'

Actual results:

$ echo $LINES ; resize ; echo $LINES
24
COLUMNS=80;
LINES=40;
export COLUMNS LINES;
40


Expected results:

$ echo $LINES ; resize ; echo $LINES
40
COLUMNS=80;
LINES=40;
export COLUMNS LINES;
40


As shown by the actual results, the problem is that creating a new tab in an 80x40 konsole window results in LINES=24 initially, confusing apps using ncurses.  Resizing the window or running 'resize' corrects the value of $LINES, but should nto be necessary.
Comment 8 Robert Knight 2009-06-05 17:07:26 UTC
Confirmed with trunk r972351
Comment 9 Jonathan Wakely 2009-06-26 13:34:36 UTC
Thanks for confirming it Robert.  Now, if anyone has a clue where to start looking to fix this, I'll happily fix it myself, as I find it very annoying.

I grabbed the konsole code and couldn't find anything obvious that caused it, but I don't know the code and didn't spend long familiarising myself with it.

It seems that the konsole process has some value of LINES that differs from the environment of the process in the first tab, because although the first tab has the correct values, opening a new tab does not.  Also, this aspect of the behaviour seems relevant:

1. Close all konsole windows
2. Open new konsole window, resize to 80x40, close window.
3a. Open konsole window.
3b. Maximise the konsole window.
3c. Restore the konsole window to 80x40.
3d. Open new tab.
4. In the new tab run 'echo $LINES ; resize ; echo $LINES'

Even after resizing (causing a SIGWINCH to be delivered to the process in the first tab) the second and subsequent tabs do not have the right value.  That implies to me that the values are being stored somewhere else, separate from the first tab.  I don't understand why the first tab's shell gets the right values if konsole doesn't have them, and I don't understand why this *only* happens with an 80x40 window, not any other size.

As I said, if anyone can give me a pointer to the relevant bit of Konsole, the KDE libs, or Qt, I'll try to fix it, but I need a clue as most of my code runs in headless servers and libraries, not GUIs.
Comment 10 Robert Knight 2009-06-26 23:12:23 UTC
In kdebase/apps/konsole/src:

The size of the the window as seen by the terminal application in lines/columns is set in Pty::setWindowSize().  The sequence of calls leading from the display widget (TerminalDisplay) when it is created or resized by the user to actually changing the size of the terminal window is:

TerminalDisplay::resizeEvent() -> TerminalDisplay::changedContentSizeSignal() -> Session::onViewSizeChange() -> Session::updateTerminalSize() -> Emulation::setImageSize() -> Session::imageSizeChanged() -> Session::updateWindowSize() -> Pty::setWindowSize()
Comment 11 Kurt Hindenburg 2009-06-29 03:05:59 UTC
In Emulation.cpp, 40,80 is the default size of the screen.

There is a 'if' check in the setImageSize method that is not triggered with the actual setting of the window is 40,80 and therefore 'imageSizeChanged' is not emitted.  This emit-ting is what sets the shell's lines/columns.
Comment 12 Jonathan Wakely 2009-06-30 00:17:52 UTC
thanks guys!  So one solution would be to add a flag to the Emulation class, initially false and set to true when imageSizeChanged is emitted. The condition in setImageSize() would check the flag as well as comparing the current sizes to the new size.  That would mean checking the flag every time, when it's only needed on the first setImageSize call for a given object, so I'll look into a better fix.
Comment 13 Gabriel Ramirez 2010-02-14 05:23:06 UTC
(In reply to comment #11)
> In Emulation.cpp, 40,80 is the default size of the screen.
> 
> There is a 'if' check in the setImageSize method that is not triggered with the
> actual setting of the window is 40,80 and therefore 'imageSizeChanged' is not
> emitted.  This emit-ting is what sets the shell's lines/columns.

I'm running kde SC 4.4 in Fedora 12 
kdebase-4.4.0-3.fc12.i686

and this bug happens again

but previous KDE SC 4.4 RCs ( 4.3.98 4.3.95) hasn't this bug

Gabriel
Comment 14 Vasilis Vasaitis 2010-04-24 13:54:24 UTC
Confirming this too. I'm running KDE 4.4.2 on Debian unstable (packages from Debian experimental). For me this bug manifests like this: when I start KDE, my session restores an 80x40 Konsole window with multiple tabs. On the tab that's active when Konsole is launched, in-terminal applications are correctly being told that the terminal is 80x40. On any other tab, however, they think that the terminal is 80x24. If I resize Konsole the size information becomes correct for the active tab only; so I have to repeat a resizing ritual for every tab I want to "fix".
Comment 15 Alain BAECKEROOT 2010-07-25 14:06:22 UTC
It seems that konsole swaps informations of COLUMNS and LINES in Ubuntu 9.10 Karmic:
ii  konsole                                    4:4.3.2-0ubuntu3


$ resize
COLUMNS=121;
LINES=45;
export COLUMNS LINES;

$ vim /tmp/a
then i tell vim that the console is 122 columns (:set co=122) then i quit
and the konsole is totally screwed 

$ echo $COLUMNS $LINES
45 122

until i resize it with mouse (just enlarge it by one column)
$ echo $COLUMNS $LINES
122 45

I have no trouble if i do the same in xterm.
Comment 16 Alain BAECKEROOT 2010-07-25 14:12:44 UTC
In gnome-terminal (from ubuntu karmic) resizing the above (broken?) example works flawlessly, and a resize inside vi induces a resize of the terminal.

ii  gnome-terminal                             2.28.1-0ubuntu1
Comment 17 Chris Samuel 2010-10-11 14:09:52 UTC
Issue still exists with Konsole 2.5.2 in KDE 4.5.2 (backports PPA from Kubuntu 10.10).
Comment 18 Nikos Chantziaras 2011-01-04 18:39:53 UTC
(The following is from bug 203185, and I suspect the issue is related.)

I've written some example C code to trigger the bug.  It's getting the terminal
size using the TIOCGWINSZ ioctl to get the terminal size.  The TIOCGWINSZ ioctl
call reports the correct size only when not using Konsole's -e option.  With
the -e option, the size is always reported as 0x0:

#include <stdio.h>
#include <sys/ioctl.h>
#include <termios.h>

int main( void )
{
    struct winsize size;
    size.ws_col = size.ws_row = 0;
    if (ioctl(0, TIOCGWINSZ, &size) < 0) {
        printf("Error: ioctl failed.\n");
        return 1;
    }
    printf("Terminal size: %dx%d\n", size.ws_col, size.ws_row);
    printf("[ENTER to quit.]");
    scanf("%*[^\n]");
    return 0;
}

Build the program (gcc filename.c) and run it first with:

  ./a.out

and then with:

  konsole -e ./a.out

If in the second case the result is 0x0, then you confirmed the bug.
Comment 19 Martin von Gagern 2011-04-06 09:48:25 UTC
Created attachment 58619 [details]
Flag to emit imageSizeChanged once

(In reply to comment #12)
> So one solution would be to add a flag to the Emulation class, initially
> false and set to true when imageSizeChanged is emitted. The condition in
> setImageSize() would check the flag as well as comparing the current sizes
> to the new size.

Implemented this, patch attached. Works as expected. Thanks for pointing out the relevant piece of code!

> That would mean checking the flag every time, when it's only needed on the
> first setImageSize call for a given object, so I'll look into a better fix.

Added a gdb breakpoint and found that there are two calls to Emulation::setImageSize during creation of a new window. But boths parts go through the resize codepath for a long while, so adding a simple "emit size setting now" call to either one seemed too much of a burden. After all, resizes are slow as hell already, that bit of added code will hardly make a difference.

An alternative would be to change the default screen sizes in the constructor. One could either choose 24x80 as the default screen size, as this is what most apps seem to expect, or 1x1, as this is almost certainly different from any screen size actually used. The first approach relies on defaults which need not be fixed, and should therefore be avoided. Both approaches force a resize of the screens created in the constructor, which is some overhead I'd like to avoid.
Comment 20 Martin von Gagern 2011-04-06 10:27:35 UTC
(In reply to comment #15)
> It seems that konsole swaps informations of COLUMNS and LINES in Ubuntu 9.10

That's bug 245746 I'd say. I doubt my patch will fix that, but give it a try.

(In reply to comment #18)
> (The following is from bug 203185, and I suspect the issue is related.)

Only remotely related, I'd say: this here is about wrong size while the window shows, while that one is about wrong size at app startup, while the window is still invisible.
Comment 21 Jekyll Wu 2011-07-20 10:44:23 UTC
Created attachment 62013 [details]
make sure pty device have proper size info 

This bug and #203185 are caused by the same reason: when the terminal process(shell,vi,mc,etc) starts and queries the pty device about size , the pty device has not been told of the proper size by konsole. So the initial size , 0x0, is returned to the terminal process.

The details are not the same :

a). in this bug, SIGNAL(imageSizeChanged()) is not emitted, because the initial size and default size happens to be the same, 80x40. 

b). in #203185,  SIGNAL(imageSizeChanged()) is emitted, but terminal process start too quickly so it still gets 0x0. That is a race condition.

The attached patch tries to guarantee that when terminal process starts and queries the pty device about size, it always get the proper size. It's similar to martin's patch, but also considers #203185. 

This patch uses a hard-coded delay, which is not elegant but works well in practice. Feel free to make any modification to it.
Comment 22 Jekyll Wu 2011-07-30 17:34:35 UTC
*** Bug 229058 has been marked as a duplicate of this bug. ***
Comment 23 Jekyll Wu 2011-07-30 19:08:33 UTC
*** Bug 244183 has been marked as a duplicate of this bug. ***
Comment 24 Jekyll Wu 2011-08-01 13:31:59 UTC
*** Bug 236405 has been marked as a duplicate of this bug. ***
Comment 25 George Labuschagne 2011-08-03 21:06:06 UTC
Hi,

In which KDE release will this bug be patched?
Comment 26 Jekyll Wu 2011-08-04 10:22:25 UTC
*** Bug 199714 has been marked as a duplicate of this bug. ***
Comment 27 Jekyll Wu 2011-08-04 16:57:54 UTC
*** Bug 173999 has been marked as a duplicate of this bug. ***
Comment 28 Kurt Hindenburg 2011-08-05 14:47:41 UTC
Git commit 7e00edd5166096feb59ffa694b6a6ff858fe1924 by Kurt Hindenburg.
Committed on 05/08/2011 at 16:40.
Pushed by hindenburg into branch 'master'.

Make sure pty device has right size before terminal process queries it.

Whenever TeminalDisplay is resized, konsole tells the underlying
pty device its new size by calling Pty::setWindowSize(). However,
current code can't guarantee when the terminal process starts and
queries the pty device about its size, the pty device already has the
right info. This has caused some long known bugs, such as #176902.

This patch tries to guarantee that important assumption. It currently
uses a hard-coded small delay, which works pretty well in practice
although not that elegant.

Patch by Jekyll Wu <adaptee@gmail.com>

I think this is better than leaving the situation as it is.  This may
be backported if no issues are found.
BUG: 173999
BUG: 176902
BUG: 203185
BUG: 229058
REVIEW: 102061
FIXED-IN: 4.8

M  +7    -0    src/Emulation.h
M  +0    -1    src/Application.cpp
M  +1    -0    src/Session.cpp
M  +30   -6    src/Emulation.cpp

http://commits.kde.org/konsole/7e00edd5166096feb59ffa694b6a6ff858fe1924
Comment 29 Jonathan Wakely 2011-08-05 14:58:09 UTC
Many thanks for getting this fixed!
Comment 30 Jekyll Wu 2011-10-20 09:06:26 UTC
*** Bug 284523 has been marked as a duplicate of this bug. ***
Comment 31 Dan Liston 2012-01-18 01:26:05 UTC
80 columns by 40 lines still malfunctioning as of konsole 2.3.3 on kde 4.3.4
At first I thought it was specifically related to the show new/close tab buttons, but the results are the same with or without the option checked.  Resizing window to anything but 80x40 seems to clear up the situation.  stty -a reports line=0 regardless of the position of the prompt within the window.
Comment 32 Jonathan Wakely 2012-01-18 08:16:32 UTC
(In reply to comment #31)
> 80 columns by 40 lines still malfunctioning as of konsole 2.3.3 on kde 4.3.4

That version is quite old, comment 17 already confirms the bug was still present in kde 4.5 so of course it's in 4.3