Bug 164540

Hi Kris,

I don't have access to FreeBSD unfortunately and I suspect that this is a platform-specific problem.  I suggest asking about this on the kde-freebsd mailing list or the #kde-freebsd IRC channel to see if anyone else using FreeBSD can confirm the problem.

http://freebsd.kde.org/contact.php

Hi Adriaan,

Are you still using FreeBSD?  Can you confirm this?

On Saturday 21 June 2008 11:44:45 Robert Knight wrote:
> Are you still using FreeBSD?  Can you confirm this?


Yes, confirmed. Bash (or whatever shell) is started by konsole but it never 
brings up an actual konsole session.

Yea, I've done some digging through the code on this, but so far have had no luck finding where the problem is occurring. I know that shell sessions *are* being started, or any command given with a -e for that matter, and the command / sessions don't finish up until close konsole or the tab. This is all normal operation it seems, but somewhere in the code where it communicates between the shell session / konsole window something is amiss.

I'll be willing to continue looking into this, any tips on where I should focus my efforts? Any place in the code where it tends to be more linux specific and may break on other systems?

There is very little Linux-specific code in Konsole itself.  My guess is that the problem is in the kpty code (the classes in kdelibs/kpty) which Konsole uses to open a connection to the terminal.

*** Bug 164905 has been marked as a duplicate of this bug. ***

*** This bug has been confirmed by popular vote. ***

Confirmed,FreeBSD (i386) release 8.0-CURRENT;
KDE 4.0.83 (4.1 beta 2).

Robert Knight's suggestion that it is in the kpty code is correct. The kpty test cases that move data all fail on FreeBSD (only initTestCase() and cleanupTestCase() pass).

miwi pointed out to me that http://websvn.kde.org/trunk/KDE/kdelibs/kpty/kpty.cpp?r1=778431&r2=797384 (the last commit in kpty) is what breaks this, although I'm not quite understanding why this is a problem.

> The kpty test cases that move data all fail on FreeBSD

Fail where though?  If you run ./kptyprocesstest from the kpty/tests build directory it should give you the line number and statement where each test failed.

The code which changed in the aforementioned commit is on a path which doesn't get called in normal Konsole usage, although the test cases do check it.

[kdetest@maki ~/kdesvn/build/kdelibs/kpty/tests]$ ./kptyprocesstest
********* Start testing of KPtyProcessTest *********
Config: Using QTest library 4.4.0, Qt 4.4.0
PASS   : KPtyProcessTest::initTestCase()
FAIL!  : KPtyProcessTest::test_pty_basic() Compared values are not the same
   Actual (output):
   Expected (QLatin1String("1: test\r\n2: test\r\n")): 1: test?
2: test?

   Loc: [/home/kdetest/kdesvn/kdelibs/kpty/tests/kptyprocesstest.cpp(114)]
FAIL!  : KPtyProcessTest::test_pty_signals() Compared values are not the same
   Actual (QLatin1String(log)): <|$
<<<<
   Expected (QLatin1String(want)): <>bla?
$
!
<!
<>foobar?
$
!
<>fooish?
$
>bar?
$
!
<|$

   Loc: [/home/kdetest/kdesvn/kdelibs/kpty/tests/kptyprocesstest.cpp(180)]
FAIL!  : KPtyProcessTest::test_ctty() Compared values are not the same
   Actual (output):
   Expected (QLatin1String("this is a test\r\n")): this is a test?

   Loc: [/home/kdetest/kdesvn/kdelibs/kpty/tests/kptyprocesstest.cpp(191)]
FAIL!  : KPtyProcessTest::test_shared_pty() 'p.pty()->waitForReadyRead(1000)' returned FALSE. ()
   Loc: [/home/kdetest/kdesvn/kdelibs/kpty/tests/kptyprocesstest.cpp(76)]
QWARN  : KPtyProcessTest::test_shared_pty() QProcess: Destroyed while process is still running.
QWARN  : KPtyProcessTest::test_shared_pty() QProcess: Destroyed while process is still running.
FAIL!  : KPtyProcessTest::test_suspend_pty() 'p.pty()->waitForReadyRead(1500)' returned FALSE. ()
   Loc: [/home/kdetest/kdesvn/kdelibs/kpty/tests/kptyprocesstest.cpp(35)]
QWARN  : KPtyProcessTest::test_suspend_pty() QProcess: Destroyed while process is still running.
PASS   : KPtyProcessTest::cleanupTestCase()
Totals: 2 passed, 5 failed, 0 skipped
********* Finished testing of KPtyProcessTest *********
QProcess: Destroyed while process is still running.
[kdetest@maki ~/kdesvn/build/kdelibs/kpty/tests]$        

I've just sent over a pretty long e-mail to the freebsd-kde list about this bug, with some of my findings about it so far.

http://mail.kde.org/pipermail/kde-freebsd/2008-July/002892.html

However, here's probably the important part, which I haven't been able to figure out yet:

(Cut from the e-mail)

I then started going through the kpty code, and placed in markers until I was able to determine where the failure was occurring exactly, in the kpty/kptydevice.cpp file, specifically this function:

-----------------------------------------------------------

bool KPtyDevicePrivate::_k_canRead()
{
    Q_Q(KPtyDevice);
    qint64 readBytes = 0;

#ifdef Q_OS_IRIX // this should use a config define, but how to check it?
    size_t available;
#else
    int available;
#endif
    if (!::ioctl(q->masterFd(), FIONREAD, (char *) &available)) {
        char *ptr = readBuffer.reserve(available);
        NO_INTR(readBytes, read(q->masterFd(), ptr, available));
        if (readBytes < 0) {
            q->setErrorString(I18N_NOOP("Error reading from PTY"));
            return false;
        }
        readBuffer.unreserve(available - readBytes); // *should* be a no-op
    }

........................ cut .......................

}
----------------------------------------------------------

The failure speficially is happening with the "ioctl" line here:

if (!::ioctl(q->masterFd(), FIONREAD, (char *) &available)) {

ioctl keeps returning -1 and setting errno to 35, which is this:
#define EAGAIN          35              /* Resource temporarily unavailable */ 

Here are additional observations by Pawel Wieczorek in case someone doesn't read the whole kde-freebsd@kde.org thread:

"I checked if terminal is setted correctly and if sub-process is runned
on this terminal. On my host (fbsd 7-stable) it is good.

I checked by small program http://trzask.int.pl/~wieczyk/shellttyinfo.c
if sub-process is set on pty correctly, and it looks good.

I addedd many stupid-debug-message to konsole and kpty code. I detect
that somethink is closing terminal (read 0 bytes from terminal). When
i commented every call to close-syscall problem still exists (this same
when i commented setting closed-on-exec flag).

From code I cannot understand kpty.cpp:324, why we want to call
revoke() on terminal ? I think this syscall is problem, from man-page
i can read that revoke is invaliding and closing every descriptor connected
to this path, maybe this syscall is invaliding terminal descriptor on
konsole process ?."

I spent a good portion of today working on this bug, and so far haven't been able to solve it. I looked into the problem mentioned previously with revoke(), however, it doesn't actually get used on FreeBSD. On my system here, it is using openpty() (HAVE_OPENPTY), which supersedes any usage of revoke(). I'm still back to square one, trying to figure out why the _k_canRead() function keeps reporting that there is no read data available. 

At this point I'm willing to try anything to get this fixed. I'll even keep a system online and provide SSH access to any developers who want to take a crack at fixing it. If somebody wants to do that, please let me know at kris@pcbsd.org. 

Thanks!

Hi Kris,

> I'll even keep a system online and provide SSH access to any developers
>  who want to take a crack at fixing it

If you can set up a suitable system I'll have a go.  Please make sure that gdb and an strace equivalent (truss?) are available.

Hi,

On FreeBSD-7 I changed ioctl command from FIONREAD to TIOCOUTQ and it repair
problem on my host. I think this problem is more connected to FreeBSD pty
driver. As I can read on pty(4) manual page, we can be sure slave-device is
terminal, but we don't know if master-device is implementing whole 
tty(4)-interface (we are calling FIONREAD on master-device). 
...or it is old bug in BSD pty.

Could anyone check if this problem exists on tty_pts driver (FreeBSD-8) ?

I can also confirm that changing FIONREAD to TIOCOUTQ does fix up kpty to the point where Konsole works fine now. However, 2 of the tests still fail, so there probably is a bit more work to be done to ensure it is 100% functional. 

It seems those problems has been fixed ? 

I'm using PCBSD 8.2(based upon FreeBSD 8.2-RELEASE), KDE-4.5.5 and konsole-2.5.4. I have not noticed those weired behavior.

While Konsole indeed works now, the kpty tests are still failing:

Config: Using QtTest library 5.7.1, Qt 5.7.1 (x86_64-little_endian-lp64 shared (dynamic) debug build; by Clang 3.8.0 (tags/RELEASE_380/final 262564))
PASS   : KPtyProcessTest::initTestCase()
QDEBUG : KPtyProcessTest::test_pty_basic() 0 bytes available, waiting
FAIL!  : KPtyProcessTest::test_pty_basic() 'p.pty()->waitForReadyRead(5000)' returned FALSE. ()
   Loc: [/root/kderoot/download/git/kpty/autotests/kptyprocesstest.cpp(132)]
PASS   : KPtyProcessTest::test_pty_signals()
FAIL!  : KPtyProcessTest::test_ctty() Compared values are not the same
   Actual   (output)                             : ""
   Expected (QLatin1String("this is a test\r\n")): "this is a test\r\n"
   Loc: [/root/kderoot/download/git/kpty/autotests/kptyprocesstest.cpp(219)]
PASS   : KPtyProcessTest::test_shared_pty()
PASS   : KPtyProcessTest::test_suspend_pty()
PASS   : KPtyProcessTest::cleanupTestCase()
Totals: 5 passed, 2 failed, 0 skipped, 0 blacklisted, 2158ms

I dig this out up to KPtyDevicePrivate::_k_canRead() method. When p.pty()->waitForReadyRead(5000) is called, this function return 0 in available for ::ioctl(q->masterFd(), PTY_BYTES_AVAILABLE, (char *) &available) call. This, in turn, leads to readBytes = 0 and method returning false.

I haven't yet figured out what to do with this.