Version: (using KDE KDE 3.4.0) Installed from: Slackware Packages Compiler: gcc-3.3.5 OS: Linux After using konsole a while, the CTRL-D combination stops working in all the tabs. Sometimes it happens sooner, sometimes later, I couldn't find a way to reproduce the problem.
Ctrl+D doesn't have any special meaning for Konsole. It simply sends that to the terminal. What did you expect to happen that isn't happening?
Sorry, what I meant is that the CTRL-D combination doesn't get to the application. For example, my Bash is setup as such that it logout's on receiving CTRL-D. Also the python interpreter will exit if I press CTRL-D. But after some time using Konsole, this doesn't happen. For example I wrote this simple C program. #include <stdio.h> int main () { char a = getchar(); printf("%d\n", a); return 0; } When Konsole works ok, I get a -1 response when I press CTRL-D (and the same happens in xterm too). When it doesn't work, hothing happens, my program never "sees" the CTRL-D.
This issue doesn't happen with xterm either? I've never seen this problem happen to me...
I think I've found a way to reproduce the error. I have several sessions defined in Konsole that directly execute "ssh root@somehost". 1. Open 2 sessions (local or remote, it doesn't matter). 2. Close any session, doesn't matter which one. 3. Open one of the remote (ssh) sessions. After this CTRL-D doesn't work any more... Actually in step 3 it doesn't have to be a remote session, a 'su -' session behaves the same. At the same time I can open and close as many standard 'Shell' sesssions I want and this problem will never happen... I also created a 'su -c bash' session, and even when opening and closing this session I didn't have any problem, ie CTRL-D still worked.
I currently don't have another machine to ssh into at this time. I tried following your example using Session->New Root Shell and I couldn't reproduce. Your step 3; which session doesn't Ctrl-D work in?
> Your step 3; which session doesn't Ctrl-D work in? In all sessions in that konsole process. Would anyone like me to enable him VNC access?
I can't reproduce this. I followed your steps and Ctrl+D still closed the sessions. Kurt: you don't need a remote machine. Run sshd on your machine and ssh into it.
I can't reproduce either; I used 'ssh localhost' as the ssh command. I'll try it in 3.4.1, but there shouldn't be much difference. https://bugs.kde.org/show_bug.cgi?id=105617 https://bugs.kde.org/show_bug.cgi?id=102199 are also ssh related.
This problem I have is not SSH related... as a matter of fact I just made a session that executes the python interpreter directly. I can reproduce the problem with that session too. my jabberid is damjan@bagra.net.mk if anyone wants to contact me, I can provide a VNC session.
Just tried kde-3.4.1 from slackware-current packages, unfortunenately I can still reproduce this bug.
I discovered one more thing, I just deleted my .kde/share/config/konsolerc file... the bug doesn't happen with a clean konsolerc. But, the bug reappears when I make the tabbar to be on the bottom of konsole. So to reproduce: 0. Right click on the tabbar, and select "Tab Bar" => Bottom
This bug is still present in 3.5.2 (using Slackware packages for 10.2 from download.kde.org). It seems that the "Tab bar" must be at the bottom position so that the bug appears.
This may be the same bug as #44077. I'm using the Slackware supplied QT (qt-3.3.4) which as far as I know is vanilla QT from trolltech.
I can't reproduce this at all... send your konsolerc that shows this bug.
Created attachment 16021 [details] my konsolerc I just attached my konsolerc file, and the bug just happend now, even without opening a SSH session, and without the tabbar on the bottom. Very strange.
Are you still using KDE 3.4.x? Your konsolerc file is quite old... please upgrade to KDE 3.5.x and reopen this if you can still reproduce.
It happens with KDE 3.5.3 on ArchLinux too. I'm testing this on a completelly new machine, and completelly new KDE config files. I'll attach my current konsolerc file. So, let me repeat: The problem happens sporadically, I can't find a reliable procedure to reproduce it, but this has happened in almost everytime when I use Konsole for a longer period of time (and I use Konsole a lot, ussually ssh-ed to a lot of other Linux boxes.) BTW I've noticed with strace, at the time when CTRL-D doesn't work, and when I press CTRL-D, konsole does something with it's bookmarks file (looks like it's saving a backup copy). Also when I open the "Configure Shortcuts" dialog in Konsole, and just click on "OK", CTRL-D suddenlly starts to work again.
Created attachment 16883 [details] konsolerc from a clean KDE 3.5 install
I've tried and tried and have never had this happen to me... I usually don't use Ctrl+D to exit my ssh sessions... I'll try to start doing that and see if I can reproduce. It is unlikely to get fixed unless there is someone to reproduce it...
> It is unlikely to get fixed unless there is someone to reproduce it... The problem is unlikely to be caused by the konsole. It is not the konsole, that treats the ctrl-d different, but the client (program) resp. the program in connection with the line discipline. Citing man:termios ----- VEOF (004, EOT, Ctrl-D) End-of-file character. More precisely: this character causes the pending tty buffer to be sent to the waiting user pro- gram without waiting for end-of-line. If it is the first character of the line, the read() in the user program returns 0, which signifies end-of-file. Recognized when ICANON is set, and then not passed as input. ----- so it may have something to do whether you are at the begin of a line, or not, perhaps. You can see the current discipline via "stty -a". What makes this stuff so obscure, is that you have a stack of ptys and terminal lines, really, i.e. konsole, bash, ssh, sshd, bash, ... where all the line disciplines on the stack are involved to finally cause your application to terminate eventually. Responsible for the termination is the very last terminal line and the very last line discipline setting program on the stack (shell, i.e.), since the other should all be raw, transparently passing ctrl-d forward, so whatever is done on the ssh'd side is the origin of the problem. The problem should be locally reproducible, cutting the stack shorter. For those who can reproduce problem (locally or remotely), i would thus suggest to try to use a different terminal emulation, e.g. xterm or linux-console, which should expose precisely the same behaviour, because they are plainly not involved in the issue. -lars
I would have to agree with the others, this is not Konsole related. Reopen, iff you can reproduce with Konsole and other terminals work.
> The problem is unlikely to be caused by the konsole. It is not the > konsole, that treats the ctrl-d different, but the client (program) resp. > the program in connection with the line discipline. Lars, please see comment 2 and also comment 17 the part about using strace. I'm fully aware that the application running inside Konsole is responsible for the doing something when ctrl-d is pressed. The problem is that nothing is sent to the application when konsole is in this "weird" state. AND the problem IS localy reproduceable, because once Konsole enters the "weird" state, ctrl-d doesn't even work for new, local shell sessions but also for every other session!!! The ssh example given at the time is only because it seemed to trigger the weird behaviour most often. ALSO, how do you explain that when konsole is in the "weird" state, ctrl-d does something with the bookmarks file, while when everything is normal ctrl-d in a shell just closes the shell and doesn't touch any bookmark files. I understand that the problem is hard to reproduce, it doesn't happen very often to me too. BUT I spend a lot of time in Konsole, and my Konsole sessions are often very long lasting for several days and weeks, maybe even months, and eventually this "weird" behaviour would happen. Once I thought it only happened to me, but eventually it happened to a coleague of mine, and that's when I decided to file a bug. As I said, if someone can leave me a jabber contact I can arrange a VNC session, when this thing happens!
And, here it is again... I was playing widly with console, opening and closing sessions, and it happened again. I have made this simplest C program that just reads one byte from stdin and dumps the char in HEX: /* test.c, compile with gcc test.c -o test */ #include <stdio.h> int main(){ char buf[10]; int i; while(1) { i = read(0, buf, 1); printf("i = %d; buf = 0x%02x\n", i, buf[0]); } } So I have this konsole window on my desktop, where: - pressing CTRL-D in any session, new or old, local or remote IS NOT received by the application inside konsole - I tried running 'exec ./test' (the program from above), it doesn't recognise that CTRL-D is pressed, while at the same time in other konsole windows (separate processes) and in Xterm it shows: i = 0; buf = 0xffffff91 - running strace on the "weird" konsole it shows this when CTRL-D is pressed lstat64("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat64("/home/damjan", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat64("/home/damjan/.kde", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 lstat64("/home/damjan/.kde/share", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 lstat64("/home/damjan/.kde/share/apps", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 lstat64("/home/damjan/.kde/share/apps/konsole", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 lstat64("/home/damjan/.kde/share/apps/konsole/bookmarks.xml.tbcache", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 access("/home/damjan/.kde/share/apps/konsole/bookmarks.xml.tbcache", W_OK) = 0 open("/home/damjan/.kde/share/apps/konsole/bookmarks.xml.tbcache02F18b.new", O_RDWR|O_CREAT|O_EXCL, 0600) = 11 umask(0) = 022 umask(022) = 0 fchmod(11, 0644) = 0 getgid32() = 100 getuid32() = 1000 fchown32(11, 1000, 100) = 0 fcntl64(11, F_SETFD, FD_CLOEXEC) = 0 stat64("/home/damjan/.kde/share/apps/konsole/bookmarks.xml.tbcache", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 getuid32() = 1000 getgid32() = 100 fchmod(11, 0100644) = 0 fcntl64(11, F_GETFL) = 0x2 (flags O_RDWR) fstat64(11, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xa76d6000 _llseek(11, 0, [0], SEEK_CUR) = 0 fstat64(11, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 read(11, "", 4096) = 0 fdatasync(11) = 0 close(11) = 0 munmap(0xa76d6000, 4096) = 0 rename("/home/damjan/.kde/share/apps/konsole/bookmarks.xml.tbcache02F18b.new", "/home/damjan/.kde/share/apps/konsole/bookmarks.xml.tbcache") = 0 BUT this doesn't happen in a konsole process that's normal (not in the weird state).
gdamjan, i understand that you swear stone and bone that the konsole truly gets into some weird mode sometimes, and that the problem is caused by the konsole. Only that the konsole does not have any special treatment of the ctrl-d. It is hard to diagnose further from our sides. Please, if you get into this state, make some test to gain further information. I would be interested to know if further keys are affected, then, too. You might for instance run the following variant of your program to try out other keys, in particular 0..9, a..z and ctrl-a..z, F1-F12. --------------------------- #include <stdio.h> #include <termios.h> int main() { printf("Press 'q' to exit\n"); unsigned char buf = 0; struct termios termios_sav; tcgetattr(0, &termios_sav); struct termios termios_now = termios_sav; cfmakeraw(&termios_now); tcsetattr(0, TCSANOW, &termios_now); while (1) { read(0, &buf, 1); printf("0x%02x (%c)\r\n", buf, buf<' '?'.':buf); if (buf == 'q') break; } tcsetattr(0, TCSANOW, &termios_sav); return 0; } ------------ I would also be interested to learn, if other application work as usual in this state. It all sound a bit like a hanging "Alt" mode on your keyboard or something alike making shortcuts running wild. Do you have any special shortcuts defined? -lars
> i understand that you swear stone and bone that the konsole truly gets into > some weird mode sometimes, and that the problem is caused by the konsole. > > Only that the konsole does not have any special treatment of the ctrl-d. > It is hard to diagnose further from our sides. Lars, I know it's a weird problem, since it does happen very sporadically and only under certain circumstances, and I know it's hard to diagnose it... but that's one reason I'm determined to push you to see through it (the other is that I'm a heavy Konsole user). > Please, if you get into this state, make some test to gain further information. Sure, I have Konsole in that state now and I can keep it running as long suspend resume works on my laptop... I'd be glad to make any tests necesseary. > I would be interested to know if further keys are affected, then, too. No, not a single other key is affected (I've tried all ctrl- and alt- combinations, even alt-d is registered) nor any other applications, as much as I can see. I have at this momment two konsoles open, running your test program, in one Konsole when ctrl-d is pressed I get "0x04 (.)", but in the other nothing shows. The only other peculiar thing I see is that ctrl-2 doesn't show anything in BOTH Konsoles, is this normal? > Do you have any special shortcuts defined? Nothing specific, but I'm using the Windows scheme (with Win key) as a global shortcut scheme (that's in settings -> regional & accessibility -> keyboard shortcuts). I have no custom shortcuts defined in Konsole. It's interesting that ctrl-d does something with the konsole bookmarks file (but only when konsole is in the weird state), and ctrl-d IS defined in Konqueror as a "add bookmark" action by default. Also if just enter in the Konsoles "configure shortcuts" dialog box the weird Konsole becomes normal again... I somehow think it's connected.
gdamjan, Kurt, in the moment, i must admit, that i'm through with my latin. My diagnosis so far is to assume that something in the earlier keyboard pipeline is broken. If you don't get a ctrl-d through to the test program, it is likely that the konsole's key processing itself does not receive it. The key events are received in bool TEWidget::eventFilter( QObject *obj, QEvent *e ) and routed there via 'emit keyPressedSignal(ke)' to void TEmuVt102::onKeyPress( QKeyEvent* ev ), and finally written to the pty. One could add an extra diagnostic into the konsole code to verify it, but i would assume this is true from your test. Any other conclusion should have an effect on other keys, too. The problem is, that i do not know how the earlier key event processing functions, i.e. which filters are applied earlier in the pipeline. That the cntl-d somehow ends in the konsole-bookmark procedures, which has been demonstrated by an ptrace in one of your earlier posts supports this diagnosis. Likely, that no other konsoles and programs are affected in this state unburdens other programs e.g. the window manager, running on the same desktop. Thus, i would localise the origin of the effect somewhere in the shortcut handling in the konsole. If this is the origin, too, remains to be seen. This bug might well be one that occurs far from its origin. This means we would have to consider library material here. From the other side, one could attack it from the KonsoleBookmarkHandler's side. Since you are determined to help here, and you can reproduce the problem within a day or so, we could try diagnose further. It might take some tests. Personally, i cannot help here further, since i do not know enough to design a proper test for shortcut material. So we have to get to the right expert here. Kurt, do you know, who takes care of the shortcut stuff right now? Perhaps the facts we found so far, might already resemble him to something... -lars PS. The sequences Ctrl-0 ... Ctrl-9 should result in '1'..'9'. Again, what you see in the test program is what the konsole actually receives as a keyevent. Actually, i'd consider the different values artefacts, bugs, really, but they have nothing to do with our issue.
*** This bug has been confirmed by popular vote. ***
Using 1.6.6. Still happening, still irreproducible.
KDE 3 is no longer supported. Reopen if you can produce this in KDE4. Thanks.
Git commit a9455a6348d9095528a222727755a105cc782812 by Ralf Engels. Committed on 16/02/2013 at 13:35. Pushed by rengels into branch 'master'. Add playlist export action to Playlist Dock save action. Let's summarize what is wrong with the current UI design (from my standpoint): 1. the playlist dock is the only dock that has it's own menu entry 2. inconsistency between the toolbar and the menu. You need to know where to find the option 3. toolbar button with multiple options is evil. You need to do a long press and the only indication that a user can do this is a tiny arrow. 4. toolbar is hidden as the playlist tab has in principle two. Hidden in this respect means that it's easy to overlook since people normally read from the top and the playlist dock has already an option bar at the top. So why look at the bottom? In principle this patch improves on point 2. FIXED-IN: 2.8 M +4 -1 src/playlist/PlaylistDock.cpp http://commits.kde.org/amarok/a9455a6348d9095528a222727755a105cc782812
(In reply to comment #30) > Git commit a9455a6348d9095528a222727755a105cc782812 by Ralf Engels. > Committed on 16/02/2013 at 13:35. > Pushed by rengels into branch 'master'. > > Add playlist export action to Playlist Dock save action. That commit uses some wrong number in its commit hook. re-close this ticket in a proper way.