[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [kdelibs] [Bug 324013] NULL pointer dereference in KPtyDevicePrivate::doWait
From:       Michael Pyne <mpyne () kde ! org>
Date:       2013-08-26 1:33:08
Message-ID: bug-324013-17878-JYidrjmhoW () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=324013

Michael Pyne <mpyne@kde.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mpyne@kde.org, ossi@kde.org

--- Comment #2 from Michael Pyne <mpyne@kde.org> ---
Most of KPtyDevice seems to pay no mind to whether readNotifier is valid, as
the object is created as part of opening the PTY. The only exception seems to
be if there is already a master file descriptor setup.

So I think the proposed fix is inappropriate, as presumably many more null
checks would be needed.

I believe the actual bug is in the testcase itself. KPtyProcess::start() is
really KProcess::start(), which is documented as starting the process, waiting
for it to complete, and returning the exit code.

When utmp support is enabled, the transition from a running process to a
finished process would cause the PTY to be logged out, which invalidates all
socket notifiers (including readNotifier). In other words the process was
already allowed to run to completion and so we don't bother with its PTY
anymore; the underlying KPtyDevice is essentially in an invalid state.

I believe the test case should use p.execute() instead of p.start() with the
rest of the testcase being more-or-less satisfactory the way it is. I've CC'ed
the KPty dev to double-check my logic though.

-- 
You are receiving this mail because:
You are watching all bug changes.
[prev in list] [next in list] [prev in thread] [next in thread]