(*** This bug was imported into bugs.kde.org ***) Package: kicker Version: 1.1 (using KDE 2.9.0 3 (CVS >= 20020213)) Severity: normal Installed from: compiled sources Compiler: gcc version 2.95.4 20011002 (Debian prerelease) OS: Linux (i686) release 2.4.17 OS/Compiler notes: I have autohide set on kicker. Under heavy load (like compiling three modules of kde simultaneously in separate konsole windows) kicker autohides but doesn't come back. However even when the load has finished so the machine is idle kicker remains hidden and does not appear again. (Submitted via bugs.kde.org) (Called from KBugReport dialog)
I need more information in order to help you. I take it kicker does not cra= sh=20 or you would get the crash dialog. Does kicker appear in the process list= =20 when this happens? What if you turn off autohiding in the control center wh= en=20 it happens?
On Tuesday 26 Feb 2002 1:17 pm John Firebaugh wrote: > I need more information in order to help you. I take it kicker does not > crash or you would get the crash dialog.=20 Correct - it autohides and then does not come back - even when the heavy lo= ad=20 subsides >Does kicker appear in the process > list when this happens? Don't know - I will need to set up the test again - at the time I didn't=20 really think too hard - I had experienced the problem at least twice so I= =20 reported it but I was in the middle of compiling kde again and I had cron= =20 jobs doing important backups in the background and I couldn't get at the me= nu=20 or anything. I presume but don't know as I didn't try it before that I can either get i= n=20 via a RMB alt-f2 and the run command or via ctrl-alt-f1 QUESTION - how do I know what kicker is - all that top gives me is a load o= f=20 kdeinit processes >What if you turn off autohiding in the control > center when it happens? Not sure I understand what you mean - do you mean that with a "hidden" kick= er=20 as a result of the above bug to turn of autohiding? Also see above not sure how to run the control centre without a menu. --=20 Alan Chandler alan@chandlerfamily.org.uk
Alan Chandler wrote: >QUESTION - how do I know what kicker is - all that top gives me is a load of >kdeinit processes > ps -ax | grep kicker Greetings Matthias
On Wednesday 27 February 2002 12:54 pm Alan Chandler wrote: > >Does kicker appear in the process > > list when this happens? > > Don't know - I will need to set up the test again - at the time I didn't > really think too hard - I had experienced the problem at least twice so I > reported it but I was in the middle of compiling kde again and I had cron > jobs doing important backups in the background and I couldn't get at the > menu or anything. > > I presume but don't know as I didn't try it before that I can either get > in via a RMB alt-f2 and the run command or via ctrl-alt-f1 Yes Alt-F2 will still work. > QUESTION - how do I know what kicker is - all that top gives me is a load > of kdeinit processes ps aux | grep kicker > >What if you turn off autohiding in the control > > center when it happens? > > Not sure I understand what you mean - do you mean that with a "hidden" > kicker as a result of the above bug to turn of autohiding? What I was wondering is what happens if after kicker disappears as you describe you go to kcontrol (running it via Alt-F2 if need be) turn off autohide in the panel settings and apply. Does it reappear or not? Thanks for your help John
On Tuesday 26 Feb 2002 1:17 pm John Firebaugh wrote: > I need more information in order to help you. I take it kicker does not > crash or you would get the crash dialog. Does kicker appear in the proce= ss > list when this happens?=20 Yes - see output from ps ax | grep kicker 769 ? S 1:16 kdeinit: kicker=20=20=20=20=20=20=20=20=20=20 10276 ? S 0:00 kdeinit: kio_http http=20 /tmp/ksocket-alan/klauncher1Mh4rc.slave-socket=20 /tmp/ksocket-alan/kickerBI80gc.slave-socket 10405 ? S 0:00 kdeinit: kio_http http=20 /tmp/ksocket-alan/klauncher1Mh4rc.slave-socket=20 /tmp/ksocket-alan/kickeruaO1Ca.slave-socket 10517 ? S 0:00 kdeinit: kio_http http=20 /tmp/ksocket-alan/klauncher1Mh4rc.slave-socket=20 /tmp/ksocket-alan/kickerwMxqsb.slave-socket 10609 ? S 0:00 kdeinit: kio_http http=20 /tmp/ksocket-alan/klauncher1Mh4rc.slave-socket=20 /tmp/ksocket-alan/kickerwcZGrc.slave-socket 21019 ? S 0:00 kdeinit: kio_http http=20 /tmp/ksocket-alan/klauncher1Mh4rc.slave-socket=20 /tmp/ksocket-alan/kickerTjKUSa.slave-socket 21020 ? S 0:00 kdeinit: kio_http http=20 /tmp/ksocket-alan/klauncher1Mh4rc.slave-socket=20 /tmp/ksocket-alan/kickerB7UTqa.slave-socket 21021 ? S 0:00 kdeinit: kio_http http=20 /tmp/ksocket-alan/klauncher1Mh4rc.slave-socket=20 /tmp/ksocket-alan/kickerwpfCRb.slave-socket 21037 pts/4 R 0:00 grep kicker Don't know whether these kio_http sockets are important - they aren't there= on=20 my quiescent system What if you turn off autohiding in the control > center when it happens? Unfortunately the way I got it to go wrong was to 1) compile and install ar= ts=20 and kdelibs - then 2) build in parallel (one konsole window for each) all t= he=20 kde modules and left it overnight by the morning all the compiling had finished but kicker did not unautohid= e=20 so I did the ps ax command in a konsole window and got the above. Unfortunately I now had an incompatible installed kdelibs against kdebase e= tc=20 so kcontol crashed on startup. It took a couple of attempts by me to reali= se=20 what was going on - but in this process something caused kicker to re-appea= r. I am of course now wondering if it was the incompatible kdelibs that caused= =20 the auto unhide failure since this kde rebuild was the same task that I was= =20 undertaking last time. --=20 Alan Chandler alan@chandlerfamily.org.uk
On Thursday 28 Feb 2002 8:17 pm John Firebaugh wrote: > Hmm... I'm beginning to doubt that there is a bug here. Are you certain > that kicker wasn't just slow unhiding due to being swapped back in? Possible (I must admit I am less sure now than when I submitted the bug=20 report). But we are talking maybe 1 minute between me moving the mouse int= o=20 the unhide area and next seeing kicker. >Could > there have been an always-on-top window obscuring kicker? Definately not - the ONLY task were all in one konsole main window (lots of= =20 sub windows though) - that was NOT maximised. >Is this effect > reproduceable? Not guarenteed but when I have loaded the system up with a lot happening t= he=20 effect appears to trigger. What happened before was that I loaded the syst= em=20 up so it was pretty busy kicker dissappeared and didn't come back even=20 though I was sitting there for perhaps 10 minutes or more with the mouse in= =20 the zone at the bottom of the screen. Because the PC was running at heavy= =20 load which I wanted to keep going I got frustruated with no kicker so I wen= t=20 away whilst whatever was happening finished. In once case that was overnigh= t.=20=20 When I came back the loaded system had stopped being so some time ago but= =20 still leaving my mouse at the bottom for at least 30 seconds - probably a= =20 minute and there was no sign of it appearing (when it appears slowly under= =20 heavy load you see a narrow band at the bottom of the screen which slowly= =20 grows into the full thing - in this case there was nothing). >I've changed the autohide code recently; I don't know if you > had the new (more reliable) code when this happened. The first time (about a week ago) was from CVS about a week before that. L= ast=20 night was from the CVS update last weekend I am now running (but have not= =20 tried to reproduce the fault) from last nights CVS. What were the temporary socket files that appeared with kickers name in it? When kicker was still hidden these files were there once once kicker=20 displayed again OK these files where then gone. --=20 Alan Chandler alan@chandlerfamily.org.uk
On Wednesday 27 February 2002 11:21 pm Alan Chandler wrote: > On Tuesday 26 Feb 2002 1:17 pm John Firebaugh wrote: > > I need more information in order to help you. I take it kicker does not > > crash or you would get the crash dialog. Does kicker appear in the > > process list when this happens? > > Yes - see output from ps ax | grep kicker > > 769 ? S 1:16 kdeinit: kicker Indicating kicker is still running just fine... > Unfortunately the way I got it to go wrong was to 1) compile and install > arts and kdelibs - then 2) build in parallel (one konsole window for each) > all the kde modules and left it overnight > > by the morning all the compiling had finished but kicker did not > unautohide so I did the ps ax command in a konsole window and got the > above. > > Unfortunately I now had an incompatible installed kdelibs against kdebase > etc so kcontol crashed on startup. It took a couple of attempts by me to > realise what was going on - but in this process something caused kicker to > re-appear. Hmm... I'm beginning to doubt that there is a bug here. Are you certain that kicker wasn't just slow unhiding due to being swapped back in? Could there have been an always-on-top window obscuring kicker? Is this effect reproduceable? I've changed the autohide code recently; I don't know if you had the new (more reliable) code when this happened. > I am of course now wondering if it was the incompatible kdelibs that caused > the auto unhide failure since this kde rebuild was the same task that I was > undertaking last time. I don't think that would cause this problem.
On Thursday 28 February 2002 10:40 am Alan Chandler wrote: > >Is this effect > > reproduceable? > > Not guarenteed but when I have loaded the system up with a lot happening > the effect appears to trigger. What happened before was that I loaded the > system up so it was pretty busy kicker dissappeared and didn't come back > even though I was sitting there for perhaps 10 minutes or more with the > mouse in the zone at the bottom of the screen. Because the PC was running > at heavy load which I wanted to keep going I got frustruated with no kicker > so I went away whilst whatever was happening finished. In once case that > was overnight. When I came back the loaded system had stopped being so > some time ago but still leaving my mouse at the bottom for at least 30 > seconds - probably a minute and there was no sign of it appearing If for some reason it doesn't unhide as soon as you touch the cursor to the screen edge it probably won't ever unhide unless you move the mouse away for the edge and back. > >I've changed the autohide code recently; I don't know if you > > had the new (more reliable) code when this happened. > > The first time (about a week ago) was from CVS about a week before that. > Last night was from the CVS update last weekend I am now running (but have > not tried to reproduce the fault) from last nights CVS. Please see if you can reproduce it with the latest CVS. > What were the temporary socket files that appeared with kickers name in it? Coolo says they are socket files connecting kicker and kio_http. Do you run knewsticker (as an internal applet)? > When kicker was still hidden these files were there once once kicker > displayed again OK these files where then gone. Hmm... interesting. May be a red herring though.
On Friday 01 Mar 2002 6:02 am John Firebaugh wrote: > On Thursday 28 February 2002 10:40 am Alan Chandler wrote: > > When I came back the loaded system had stopped > > being so some time ago but still leaving my mouse at the bottom for at > > least 30 seconds - probably a minute and there was no sign of it > > appearing > > If for some reason it doesn't unhide as soon as you touch the cursor to t= he > screen edge it probably won't ever unhide unless you move the mouse away > for the edge and back. OK I made it occur again (overnight - by make clean && make on all the kde= =20 modules simultaneously) and it definately doesn't come back even if I move= =20 the mouse up and down to and from the bottom of the screen. Before I left = it=20 running overnight I had lots of manual tries to get it to lockup and it=20 didn't although everything was working very slowly (the load was such that= =20 it took 5 minutes for a new konsole to start up - but kicker would always= =20 come up within about 30/40 seconds sometimes a lot faster). Anyway in the morning I couldn't get kicker to reappear with lots of tries= =20 and=20 ps aux | grep kicker showed it was still running (along with one of those temp files from=20 newsticker) > Please see if you can reproduce it with the latest CVS. Yes - this was from CVS of Wednesday evening You also asked me to try and remove the autohide properties with kcontrol. = I=20 was able to successfully run up konsole with Alt-F2 and then run kcontrol= =20 from konsole. When I selected panel it displayed the page and then locked= =20 solid (so I couldn't tab to the hiding tab - nor could I close kcontrol=20 down). I killed kcontrol (with the kill command from konsole) and ran it again. A= ll=20 was fine until I selected "look&feel/panel" when it locked solid again=20 (although this time it didn't even display the first page of the panel=20 display). --=20 Alan Chandler alan@chandlerfamily.org.uk
You have some strange problems then. If you can reproduce the kcontrol lockup please do a "kill -6 <pid of kcontrol>" to get a proper backtrace. Please do this for kicker as well when it disappears.
On Sunday 03 Mar 2002 8:10 pm John Firebaugh wrote: > You have some strange problems then. If you can reproduce the kcontrol > lockup please do a "kill -6 <pid of kcontrol>" to get a proper backtrace. > Please do this for kicker as well when it disappears. Strange indeed. I managed another "run" last night and this morning I firs= t=20 tried to run kcontrol and unhide kicker. This time it did not lockup but= =20 allowed me to uncheck the autounhide button - but no kicker appeared. ps aux | grep kicker revealed that kicker was no longer there. What I did do was grep .xsession-errors looking for kicker - about 00:19 (I= =20 can tell because there are some kalarm entries surrounding it which gives t= he=20 times) the two lines below appeared kicker: crashHandler called DCOP: unregister 'kicker' This is not long after the time I started the test and left it for the nigh= t.=20=20 There was nothing more in the .xsession-errors log regarding this crash --=20 Alan Chandler alan@chandlerfamily.org.uk
On Monday 04 March 2002 11:14 pm Alan Chandler wrote: > On Sunday 03 Mar 2002 8:10 pm John Firebaugh wrote: > > You have some strange problems then. If you can reproduce the kcontrol > > lockup please do a "kill -6 <pid of kcontrol>" to get a proper > > backtrace. Please do this for kicker as well when it disappears. > > Strange indeed. I managed another "run" last night and this morning I > first tried to run kcontrol and unhide kicker. This time it did not lockup > but allowed me to uncheck the autounhide button - but no kicker appeared. > > ps aux | grep kicker revealed that kicker was no longer there. > > What I did do was grep .xsession-errors looking for kicker - about 00:19 (I > can tell because there are some kalarm entries surrounding it which gives > the times) the two lines below appeared > > kicker: crashHandler called > DCOP: unregister 'kicker' > > This is not long after the time I started the test and left it for the > night. There was nothing more in the .xsession-errors log regarding this > crash If I'm to have any change of fixing this you will have to get a backtrace somehow. If kicker crashed you should have gotten the crash manager dialog. If it is running and seems to be hung do a "kill -6 <pid of kicker>" and you should again get the crash manager dialog.
On Wednesday 06 Mar 2002 1:58 am John Firebaugh wrote: .. > If I'm to have any change of fixing this you will have to get a backtrace > somehow. If kicker crashed you should have gotten the crash manager > dialog. If it is running and seems to be hung do a "kill -6 <pid of > kicker>" and you should again get the crash manager dialog. It has taken me a few days to rebuild KDE from scratch with the latest CVS = -=20 but having put --enable-debug on kdebase I have had two overnight attempts = to=20 reproduce the fault and neither of them have succeeded (ie neither times ha= ve=20 kicker failed to re-appear). Since I could almost guarentee the problem previously I am inclined to thin= k=20 that either its no longer a problem following your changes of about a week= =20 ago or the --enable-debug has an effect on the timing that changes=20 behaviour. I will rebuild kdebase without the --enable-debug and try one more time --=20 Alan Chandler alan@chandlerfamily.org.uk
Thank you for your bug report. This bug can not be reproduced using the current development (CVS) version of KDE. This suggests that the bug has already been fixed. The bug report will be closed.