Bug 203185 - Wrong reported terminal dimensions when using the "-e" option
Summary: Wrong reported terminal dimensions when using the "-e" option
Status: RESOLVED FIXED
Alias: None
Product: konsole
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Platform: Gentoo Packages Unspecified
: NOR normal (vote)
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
: 269470 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-08-09 16:32 UTC by Nikos Chantziaras
Modified: 2011-08-05 14:47 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.8


Attachments
konsole -e mc (91.11 KB, image/png)
2009-08-09 16:33 UTC, Nikos Chantziaras
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nikos Chantziaras 2009-08-09 16:32:54 UTC
Version:            (using KDE 4.3.0)
Compiler:          GCC version 4.3.4 Gentoo 4.3.4 p1.0, pie-10.1.5
Installed from:    Gentoo Packages

When I run a program that uses ncurses or slang to access the terminal using the -e option, Konsole seems to report an 80x24 terminal size regardless of Konsole's real size. Running "konsole -e mc" for example (to run Midnight Commander), results in what is depicted in the screenshot I am attaching below.  Resizing Konsole fixes the problem and mc is then able to pick up the real dimensions.
Comment 1 Nikos Chantziaras 2009-08-09 16:33:40 UTC
Created attachment 36012 [details]
konsole -e mc
Comment 2 FiNeX 2009-08-09 17:04:47 UTC
I'm not able to reproduce on current trunk. Could this be fixed after 4.3 or could it be a configuration issue?
Comment 3 Nikos Chantziaras 2009-08-09 17:49:32 UTC
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;
}
Comment 4 anj.tuesday 2009-08-09 23:17:07 UTC
Your test program reports 0x0 every time, and I can confirm jumbled layouts for mc when run for the first time with a given Konsole size. (And for FrobTADS, where I first noticed the bug.)
Comment 5 Nikos Chantziaras 2009-10-12 18:15:19 UTC
The bug still persists in KDE 4.3.2. No interest in fixing this one? :-/
Comment 6 Kurt Hindenburg 2009-10-14 05:32:47 UTC
It works on my 4.3.2 machine and trunk.

konsole -e mc

SO what is different?

mc 4.7.0-pre3
Comment 7 Nikos Chantziaras 2009-10-14 05:35:11 UTC
I posted an example C program. Please use that. It demonstrates Konsole's failure to return the correct size.
Comment 8 Nikos Chantziaras 2010-02-08 05:22:13 UTC
The bug is still there in all 4.3.x versions as well as the 4.4 RCs and (the currently tagged but unreleased) 4.4.0.
Comment 9 Jonathan Wakely 2010-07-22 13:38:51 UTC
related to Bug 176902 ?
Comment 10 Jonathan Wakely 2010-07-22 13:45:56 UTC
and Bug 173999 ?
Comment 11 Nikos Chantziaras 2011-01-04 18:36:41 UTC
Issue persists with KDE 4.6 RC (4.5.90).
Comment 12 Nikos Chantziaras 2011-01-28 14:17:31 UTC
Issue persists in KDE 4.6 final.
Comment 13 Nikos Chantziaras 2011-01-28 14:22:03 UTC
Also, could someone please the status that still says "UNCONFIRMED"? It has been confirmed two years ago already.
Comment 14 Sergei Ivanov 2011-03-08 23:00:08 UTC
I see this bug in KDE 4.6.1 (kubuntu PPA packages) and have some experimental data showing that it is a race condition.

First, I tried 'konsole -e mc' on two machines and only one of them (an older and slower one) showed the bug (9 times out of 10). I've  found that a reliable test is not with mc but with stty. To reproduce, run

  konsole --hold -e stty -a

The first line of stty output (appearing in a new konsole window) is:

  speed 38400 baud; rows 0; columns 0; line = 0;

which is obviously wrong. What is interesting is that if I add a small delay before stty, like this:

  konsole --hold -e sh -c 'sleep 0.1 && stty -a'

I get the correct output from stty:

  speed 38400 baud; rows 30; columns 80; line = 0;

Adding a similar delay before mc invocation also fixes this bug (on the machine where mc is affected).

My guess is that 'konsole -e ...' launches the command before its pseudo-terminal is fully set up, and then reports the 0x0 terminal size for some period of time. Later (when the konsole window fininshes its initialization) the PTY is filled with correct dimensions but it's too late if the application has already read the  terminal size from the PTY.
Comment 15 Martin von Gagern 2011-04-06 10:07:27 UTC
(In reply to comment #14)
> My guess is that 'konsole -e ...' launches the command before its
> pseudo-terminal is fully set up, and then reports the 0x0 terminal size for
> some period of time. Later (when the konsole window fininshes its
> initialization) the PTY is filled with correct dimensions but it's too late if
> the application has already read the  terminal size from the PTY.

I agree. The following app will query the window size repeatedly; only the first time will report the 0x0 size.

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

int main( void )
{
    struct winsize size;
    for (;;) {
        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 continue, Ctrl+D to quit.]");
        if (getchar() == EOF)
            return 0;
    }
}

I guess konsole should init its pty info from its startup geometry, but I haven't looked what the code for this looks like.
Comment 16 Nikos Chantziaras 2011-06-11 19:05:32 UTC
Issue still there in 4.6.4.

Can somebody explain why this is still marked as UNCONFIRMED?
Comment 17 Jekyll Wu 2011-07-16 09:56:23 UTC
I think this bug can be marked as `new' now.

As pointed out by Sergei in comment #14, there exist a race condition. The initial window size of the Pty is 0x0, which will be updated to proper value after the TerminalDisplay widget get resized. However, current code can't guarantee the terminal process(shell, mc, etc) is started ONLY AFTER the first resizeEvent of TerminalDisplay widget has happened.

Application::createSession(...)
{
  ....
  view->createView(session);
  session->run();
  .....
}

Pty::start(...)
{
  ....
  pty()->setWinSize(_windowLines, _windowColumns);
  kDebug() << _windowColumns << "x" << _windowLines ;
  KProcess::start();
  ...
}
Comment 18 Jekyll Wu 2011-08-03 15:52:28 UTC
*** Bug 269470 has been marked as a duplicate of this bug. ***
Comment 19 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