What were you doing when the application crashed?
Can you reproduce the crash at will ?
What is your Qt version?

Thanks

Just random typing on a BASH prompt.

[I] x11-libs/qt-gui
     Installed versions:  4.4.2-r2(4)(01:27:16 01/31/09)(accessibility cups dbus mng pch qt3support tiff xinerama -debug -glib -input_devices_wacom -nas -nis)

Created attachment 31709 [details]
Auto generated konsole.kcrash file

konsole.kcrash file from konsole crash.

My Konsole has crashed in the past but tonight I received a crash report.
Fedora 10 - kdebase-4.2.0-6.fc10.i386

Konsole crashed as I was changing focus to konsole from another application.

Konsole on Desktop 2.

Running multiple tabs (3 at least). One was running a bash script.

@Robin: your crash seems to be a different one. If you can reproduce the crash at will, may you read http://techbase.kde.org/Development/Tutorials/Debugging/How_to_create_useful_crash_reports and post a complete backtrace in a NEW report? 
You may need to install "libqt4-debuginfo" and "kdelibs5-debuginfo" packages
Thanks :)

I can confirm any konsole lockup/crash disables input on all other konsole tabs/instances.  Under 4.2.0/FreeBSD-current I can hang console simply by dumping any binary file to the terminal via the shell.

I hit this every once in a while when I forget to add a destination to curl and it starts spewing the binary file to the terminal.

This appears for the X session log when this happens.  This may coincide with the reporters 'typing random garbage'. ** == my comments

** startup of konsole
kdeinit4: preparing to launch /usr/local/kde4/bin/konsole
konsole(25975): Attempt to use QAction "change-profile" with KXMLGUIFactory!
** garbage being written to terminal:
Undecodable sequence: \001b(hex)"
Undecodable sequence: \001b(hex)\00e4(hex)
Undecodable sequence: \001b(hex)\00e4(hex)
[.. several thousand lines ..]
Undecodable sequence: \001b(hex)[\0088(hex)
Undecodable sequence: \001b(hex)[\0099(hex)
Undecodable sequence: \001b(hex)'
Undecodable sequence: \001b(hex)[\00bd(hex)
Undecodable sequence: \001b(hex)\00fe
** Konsole is hung everywhere
** Konsole is killed by me
QObject: Do not delete object, 'unnamed', during its event handler!
QObject: Do not delete object, 'unnamed', during its event handler!
QObject: Do not delete object, 'unnamed', during its event handler!

In KDE 4 all instances of Konsole run in a single process by default.  When Konsole is stable, as it is for the majority of users, this is not a problem and it allows easier sharing of resources and faster startup of secondary instances.

You can force a konsole to start a new process by starting it from a terminal - in which case it has to use a new process so that it inherits the environment from the terminal.

Created attachment 32454 [details]
Cat'ing this file crashes konsole - use at own risk ;-)

Cat'ing this file crashes konsole - use at own risk ;-)

Per the above attachment - this bug is readily reproducible - cat'ing it is enough to take konsole down with the same backtrace as reported by Luke-Jr.

I'm running konsole-4.2.1, qt-4.5 - also built on Gentoo.

Hint - start a new konsole before cat'ing the attachment ;-)

Here using:

Qt: 4.5.0 + qt-copy-patches-936035
KDE: 4.2.68 (KDE 4.2.68 (KDE 4.3 >= 20090327))
kdelibs svn rev. 946159 / kdebase svn rev. 946160
on ArchLinux i686 - Kernel 2.6.28.8

I can't reproduce the crash with the steps on comment 9 and the testcase file of comment 8

Can anyone else using trunk confirm this ? Thanks

@Robert Knight
Robert, putting everything in a single process is not smart and it is the main reason why I never switched to Firefox. Every software has a bug, and some of those bugs may cause program to crash. It is not biggie when only one instance crashes but today I experienced crash of 6 (six!) opened konsole instances which took down my complete work and half an hours of life until I re-generated everything. 

There were no performance problem with old konsole so I don't know why you are spending your time re-inventing the wheel? KDE 4 is terribly unstable, why not stabilize it first?

BTW, konsole crashed in KDE 4.2.4, libqt4-4.5.1+4.5.2.20090607, openSUSE 11.1.

> Robert, putting everything in a single process is not smart and
> it is the main reason why I never switched to Firefox

IF the application is stable - then it is worth it and yes - I do think the performance and sharing benefits (being able to move tabs between windows, have a settings change in one window immediately reflected in all of them) are worth it.  

>  KDE 4 is terribly unstable, why not stabilize it first?

Like most developers - I spend a large chunk of my working day with a terminal open and in use.  For me at least, Konsole is stable - even with bleeding edge builds of KDE.

I agree with comment #11. I can tolerate single-process things from Konqueror now because there is a quick method to restore my session. Can we get the same from Konsole? I imagine it might take some cooperation from the crash handler, but it would certainly be worth it.

Also, why does this help at all? With shared libraries, multiple processes shouldn't take up any significant RAM...

> Also, why does this help at all? With shared libraries,
> multiple processes shouldn't take up any significant RAM...

It saves a little memory - but not much given the amount used by Konsole per-tab for things like scrollback.  More usefully, it saves application initialization time.

> Can we get the same from Konsole?

Not properly.  In a browser, given a URL and cookies you can often get back most of the previous state of a web page.  In the terminal you would need (1) the output, (2) basic properties of the process such as command and current directory and (3) the state of the terminal program.  (2) is quite easy, (1) is do-able, although it might impose an unwanted performance hit for something not used very often and (3) is not supported by the current terminal model.  

However - although Konsole itself is obviously limited it what it can do, it makes a lot of sense to write scripts, aliases and setup Konsole profiles to help you get the terminal to a particular state quickly - even if like me you expect the terminal to be stable. 

I will mention as a tip that if you do need to start a new Konsole process for some reason - run it from a terminal and it will automatically use a new process. I don't mind adding a command-line argument for that as well.

The comparison with browsers is I think unfair on the browsers - they have to cope with much more complicated content consisting of JavaScript, images, audio, video, a complex document structure and layout and rendering system and of course the cause of a large number of browser crashes - binary plugins like Flash - which also have to cope with pretty complicated content themselves.  Plus the whole environment is evolving very quickly.  Vim today is not that much more demanding than it was 10 years ago.  Modern web applications are a world away from

As far as application init, how about having a new instance fork() the old one? ;)

Konsole already stores the scrollback in a tmp file. 2/3 are not really needed if the crash handler saves our ptys. ;)

> As far as application init, how about having a
> new instance fork() the old one? ;)

I don't know whether that is possible once the application is up and running complete with GUI.  That still leaves you without the sharing features - like being able to move tabs between windows - I'll get to that later.

> Konsole already stores the scrollback in a tmp file. 

Only for the 'unlimited' history mode, not currently for the limited scrollback used by default.  Do-able though. 

> 2/3 are not really needed
> if the crash handler saves our ptys. ;)

True - although depending on the effort involved it might not be worth it just for handling crashes in the terminal which, while potentially very annoying, happen rarely.  

An alternative setup which one of the trolls suggested to me was having a helper program like GNU-Screen with no GUI be responsible for setting up the terminal and possibly storing the output - which communicates with the Konsole UI processes.  Although then you then have the possibilty of that crashing as well - and bam, you're back to square one.

> I don't know whether that is possible once the application is up and running
> complete with GUI.

Hmm, good point. Sounds like something that should be added to Qt :-). (In fact, if NWI[1] happens it will almost *need* to be added; NWI makes application cloning a lot more important.)

> That still leaves you without the sharing features - like
> being able to move tabs between windows - I'll get to that later.

The *WM* will get to that later :-D.

If NWI (or even just tabbed WM) takes off, *I* am going to start harping at you to make Konsole process-per-tab ;-). Tab handling at that point will be a WM thing, and you can use DBUS to communicate settings changes that you want propagated.

Alternatively you can work with konq* to build an embedding container a la Chrome, so you have one process per tab plus a helper application managing the tabs (probably via xembed). Of course you need a way then to recover from the helper crashing, but at least a tab crash will only take out that tab.

(* Why work with konq? Code re-use; I think konq may already have plans to work on something like this, and even if not, it's still something konq should do. Also building the helper to be flexible from the start would probably help moving it over to NWI in the future. Bonus points for coming up with a solution where konq and konsole can exist in the same container.)

1: http://techbase.kde.org/Projects/Usability/NWI

Matthew - the problem with Konqueror was that it was jack of all trades, master of none.  Yes, it was cool that you could have an image, several PDF and a few web pages all open at once in tabs but it was never a great image viewer, never a great PDF viewer and never a great web browser.  Plus the user interface was highly context sensitive and my recent experience watching videos of users trying to use software suggests that gets really confusing.

Robert - I don't follow where you got to comment #18. I was talking about making browser tabs into their own processes, as done by Chrome and as there is pressure for Firefox to do (if it isn't done in 3.5?). This has nothing to do with konq being a "jack of all trades", I'm only thinking about it as a web browser in this context. "Process per tab" is apparently "the thing" for web browsers at the moment. I think this would benefit Konsole also, but there first needs to be infrastructure to glue the tabs together. It is a goal of NWI to achieve this, but Chrome proves it can also be done as a stand-alone app.

> Process per tab" is apparently "the thing" for web
> browsers at the moment. I think this would benefit Konsole also

As I described above, there is a big difference between what a web browser has to cope with and what Konsole deals with.

For example:

1.  For each tab, a web browser has to effectively run a complete application, with a UI declaratively specified using HTML/CSS and with logic provided by a JavaScript program.  In addition it may have to play inline video and audio, perform network requests and so on.  When you have all this interactive stuff to keep track of, it makes sense to use the kernel to schedule these applications and deliver good responsiveness and isolation.  A terminal in contrast, receives output, performs some simple 'drawing' operations on a 'canvas' and then renders that to the screen.  When it receives input, it does some simple translation of it and sends that to the terminal via a pipe.

The actual application itself containing the complex and fallible logic (the shell, Vim, ssh etc.) - which is analogous to Javascript in a web browser, is already running in another process.

2.  A web browser may have to embed Java, Flash, Silverlight etc.  These are all very large and complex pieces of code in themselves - all of them include a complete JIT compiler for a start.  A terminal's only inputs come from the file system, the pty and the user.

Chrome/IE8/Safari's multi-process model makes sense because of the inherent complexity of a web browser where the effort to do all the IPC is justified.  If you're finding the terminal unstable then I suggest the right cure would be some good unit tests and refactoring of the problematic parts.

> As I described above, there is a big difference between what a web browser has
> to cope with and what Konsole deals with.

Occasionally, Konsole crashes. Or maybe I even do something insane like 'kill <some konsole pid>' by accident. Or maybe the pty goes haywire and does something that breaks Konsole's internal state (or just makes it non-responsive, in which case a 'close tab' button that knows 'the window with <pid> is not responding' is easier to deal with than finding the pty pid, assuming that killing the pty would even be sufficient for Konsole to recover). I would MUCH rather either the container crash-and-burn (and be restartable with no pty loss at all), or a single tab die. Besides that isolating the history (memory space) is no bad thing...

If you don't want to do any proactive work (i.e. not worry about this until NWI becomes reality), that's one thing, but your objection sounds like "well my code is so perfect that it never crashes, so I have no reason to minimize the disastrousness of a crash". Need I say more?

While "don't crash" is obviously a good goal, I think a Konsole crash (as things stand now) is painful enough that "crash without taking out 20+ pty's" isn't an unreasonable idea. If a crash only took out a singly pty, I'd be more inclined to agree, but right now that's not the case.

> but your objection sounds like 
>"well my code is so perfect that it never crashes,
> so I have no reason to minimize the disastrousness of a crash"

Given that this discussion is happening in a legitimate bug report about a crash in Konsole - that is obviously not true.

What I am saying is that if Konsole is perceived to have a stability problem then I would first address it via less drastic means - like better testing.  I agree with the basic goal of containing the damage done by a bug from the user's point of view and yes I take your point that a multi-process model would help.  However, I do not think that it is the most time-effective way to improve stability right now.

I agree w/ #10.  The file doesn't crash my trunk nor KDE 4.3.5.

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

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

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

Created attachment 65226 [details]
New crash information added by DrKonqi

konsole (2.7.999) on KDE Platform 4.7.1 (4.7.1) using Qt 4.7.2

- What I was doing when the application crashed:

tried to cat ~/.local/share/akonadi/db_data/ib_logfile0

-- Backtrace (Reduced):
#11 0x00007fa49c94551e in QVector<Konsole::Character>::operator[](int) () from /usr/lib64/libkonsoleprivate.so
#12 0x00007fa49c944a6f in Konsole::Screen::displayCharacter (this=<value optimized out>, c=1866) at /var/tmp/portage/kde-base/konsole-9999/work/konsole-9999/src/Screen.cpp:661
#13 0x00007fa49c980f2a in Konsole::Vt102Emulation::receiveChar (this=0x88f450, cc=<value optimized out>) at /var/tmp/portage/kde-base/konsole-9999/work/konsole-9999/src/Vt102Emulation.cpp:342
#14 0x00007fa49c91b3ad in Konsole::Emulation::receiveData (this=0x88f450, text=0xbb8988 ": Fwd: Filme / Laptop\r\nDate: Tue, 04 Oct 2011 09:17:04 +0200\r\nMessage-ID: <1386289.K3rRsfpWlF@d-partment>\r\nUser-Agent: KMail/4.8 pre (Linux/2.6.38-tuxonice-r1; KDE/4.7.1; x86_64; git-b4c88b0; 2011-09-"..., length=4095) at /var/tmp/portage/kde-base/konsole-9999/work/konsole-9999/src/Emulation.cpp:251
#15 0x00007fa49c947a9a in Konsole::Session::onReceiveBlock (this=0x89f1a0, buf=0x7443 <Address 0x7443 out of bounds>, len=6) at /var/tmp/portage/kde-base/konsole-9999/work/konsole-9999/src/Session.cpp:1293

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

Git commit 0905a301e6eb557e11e1e1f5a736a9679ed2f0a9 by Kurt Hindenburg.
Committed on 13/11/2011 at 22:21.
Pushed by hindenburg into branch 'master'.

Prevent crashing when dumping binary files to terminal.

"cat"ing binary files often crashes Konsole.  This patch checks the
indicies.
Note that there are tons of 'undecodable sequences' that also print
out.  These likely should not be displayed unless debugging.
BUG: 184964
FIXED-IN: 4.8

M  +7    -0    src/Screen.cpp

http://commits.kde.org/konsole/0905a301e6eb557e11e1e1f5a736a9679ed2f0a9

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