From kde-core-devel Mon Jun 07 23:50:34 2004 From: "Peter Rockai \(mornfall\)" Date: Mon, 07 Jun 2004 23:50:34 +0000 To: kde-core-devel Subject: konsolePart/TerminalInterface: startProgram crashes when called Message-Id: <200406080150.34514.mornfall () danill ! sk> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=108665379520357 Hello! I have been trying to embed konsolepart in my application. While i can work around the other issues with this part (see my other post, "ExtTerminalInterface + KProcess extension for KDE 3.4/4.0"), there is one i don't really understand. The TerminalInterface provides a startProgram method, which is supposed to start a new child process in a KProcess (TEPty really, but this is a KProcess subclass). However, when the konsolePart is constructed, it sets up a immediate singleShot timer, which starts a shell in it, if no other program was started in the meantime. This, in itself, would be relatively acceptable, even while not really desirable. The other problem is, that upon execution of this program, konsolePart connects its slot konsolePart::sessionDestroyed to the TESession's (which is wrapping up the TEPty and a terminal emulator class) signal destroyed (). This signal is emitted when the running child process is terminated or TESession is destroyed by other means. This would be also ok. The problem is in the sessionDestroyed slot and the startProgram method interaction. This is what TESession does: 1017 if ( se ) delete se; 1018 se = new TESession(te, program, args, "xterm", parentWidget->winId()); and this is what sessionDestroyed does: 263 delete this; As you can see, i hope, this is really unintuitive and IMO undesirable behaviour. What happens is, when startProgram is called for the second time, or is called from a slot in my application, when an "se" object already exists, it will trigger massive amounts of invalid memory access and crash with SIGSEGV in the result. Now, i'm not really sure about the solution. I locally commented out the "delete this" call in konsolePart::sessionDestroyed, which is what i deem as rather sane. If you have other suggestions, i'd be glad to hear them. Yours, Peter PS: This issue is present both in branch and head versions.