Is someone experiment this : http://feliciano.matias.free.fr/Screenshot-Panel.png
The rhn alert icon is hide by the authentication icon.
Sorry, but i can't reproduce.
On Sat, Jul 26, 2003 at 04:38:54AM +0200, Féliciano Matias wrote:
Is someone experiment this : http://feliciano.matias.free.fr/Screenshot-Panel.png
The rhn alert icon is hide by the authentication icon.
Sorry, but i can't reproduce.
Hum, it's the infamous "1 pixel wide applet icon" bug, it's already registered in bugzilla, apparently it is a GTK bug but nobody has been able to reproduce it under debug condition to chase it down :-( Yes it's nearly impossible to reproduce ...
Daniel
My exprience is that I can never reproduce it via debugging methods.. but after I stop chasing it down.. it occurs again. Currently I recommend that we uninstall the application because the desktop support people get asked 3-4 times a day where it went
On Sat, 26 Jul 2003, Daniel Veillard wrote:
On Sat, Jul 26, 2003 at 04:38:54AM +0200, Féliciano Matias wrote:
Is someone experiment this : http://feliciano.matias.free.fr/Screenshot-Panel.png
The rhn alert icon is hide by the authentication icon.
Sorry, but i can't reproduce.
Hum, it's the infamous "1 pixel wide applet icon" bug, it's already registered in bugzilla, apparently it is a GTK bug but nobody has been able to reproduce it under debug condition to chase it down :-( Yes it's nearly impossible to reproduce ...
Daniel
Daniel Veillard wrote:
On Sat, Jul 26, 2003 at 04:38:54AM +0200, Féliciano Matias wrote:
Is someone experiment this : http://feliciano.matias.free.fr/Screenshot-Panel.png
The rhn alert icon is hide by the authentication icon.
Sorry, but i can't reproduce.
Hum, it's the infamous "1 pixel wide applet icon" bug, it's already registered in bugzilla, apparently it is a GTK bug but nobody has been able to reproduce it under debug condition to chase it down :-( Yes it's nearly impossible to reproduce ...
Daniel
oops,
i had trouble with the gnome-desktop under rhl 8.0, the keyboard gave me only beeps but other users had no problems.
i moved all ~/.* to solve it, i copyed-back .gn* .moz* .rhn-apllet.conf
i had forgotten to copy-back the .rhn-applet.cache and now i can see "1 pixel wide applet icon"
can you try this to reproduce it ?
$ mkdir home-rhn-applet $ mv .rhn-applet.cache home-rhn-apllet/
logout login
--> "1 pixel wide applet icon"
$ cp home-rhn-applet/.rhn-applt.cache .
logout login
--> all is ok
On Fri, Aug 01, 2003 at 10:49:45AM +0200, shrek-m@gmx.de wrote:
Daniel Veillard wrote:
Hum, it's the infamous "1 pixel wide applet icon" bug, it's already registered in bugzilla, apparently it is a GTK bug but nobody has been able to reproduce it under debug condition to chase it down :-( Yes it's nearly impossible to reproduce ...
oops,
i had trouble with the gnome-desktop under rhl 8.0, the keyboard gave me only beeps but other users had no problems.
i moved all ~/.* to solve it, i copyed-back .gn* .moz* .rhn-apllet.conf
i had forgotten to copy-back the .rhn-applet.cache and now i can see "1 pixel wide applet icon"
can you try this to reproduce it ?
$ mkdir home-rhn-applet $ mv .rhn-applet.cache home-rhn-apllet/
logout login
--> "1 pixel wide applet icon"
Hum, it took me two attempts but I managed to reproduce this bug for the first time !
thanks a lot, now I should be able to kill it :-)
Daniel
On Fri, Aug 01, 2003 at 09:37:55AM -0400, Daniel Veillard wrote:
On Fri, Aug 01, 2003 at 10:49:45AM +0200, shrek-m@gmx.de wrote:
i had trouble with the gnome-desktop under rhl 8.0, the keyboard gave me only beeps but other users had no problems.
i moved all ~/.* to solve it, i copyed-back .gn* .moz* .rhn-apllet.conf
i had forgotten to copy-back the .rhn-applet.cache and now i can see "1 pixel wide applet icon"
can you try this to reproduce it ?
$ mkdir home-rhn-applet $ mv .rhn-applet.cache home-rhn-apllet/
logout login
--> "1 pixel wide applet icon"
Hum, it took me two attempts but I managed to reproduce this bug for the first time !
thanks a lot, now I should be able to kill it :-)
I decided to debug this today, and tried and retried the given recipe and could not get the problem to reproduce today :-( Tried 20 times and failed ... I still don't know how to reproduce this
Damn...
Daniel
My personal '1 pixel wide' alert icon shows up almost every time I login now. I guess my comments about RHN customer service upset it... :-)
Bob Cochran
On Fri, 2003-07-25 at 22:38, Féliciano Matias wrote:
Is someone experiment this : http://feliciano.matias.free.fr/Screenshot-Panel.png
The rhn alert icon is hide by the authentication icon.
Sorry, but i can't reproduce.
On Sun, Aug 03, 2003 at 04:52:17PM -0400, Robert L Cochran wrote:
My personal '1 pixel wide' alert icon shows up almost every time I login now. I guess my comments about RHN customer service upset it... :-)
Do you have a ~/.rhn-applet.cache file ?
Daniel
Yes I do, dated July 28 at time 21:20, permissions -rw-rw-r--, file size 27
On Sun, 2003-08-03 at 16:56, Daniel Veillard wrote:
On Sun, Aug 03, 2003 at 04:52:17PM -0400, Robert L Cochran wrote:
My personal '1 pixel wide' alert icon shows up almost every time I login now. I guess my comments about RHN customer service upset it... :-)
Do you have a ~/.rhn-applet.cache file ?
Daniel
On Sun, Aug 03, 2003 at 05:12:39PM -0400, Robert L Cochran wrote:
Yes I do, dated July 28 at time 21:20, permissions -rw-rw-r--, file size 27
Hum, 27 bytes or 27 KB ? In the first case could you send me a copy in attachment, this is not normal and could explain some of the problems encountered !
Daniel
Daniel Veillard wrote:
I decided to debug this today, and tried and retried the given recipe and could not get the problem to reproduce today :-( Tried 20 times and failed ... I still don't know how to reproduce this
Damn...
i tried it once again
boot severn1 in init 5: procedure --> no "1 pixel wide applet icon" ??
boot severn1 in init 3: $ startx procedure --> no "1 pixel wide applet icon" ??
once again in shrike with some ignored-packages boot shrike in init 3 $ startx procedure --> no "1 pixel wide applet icon" ??
sh...
but now ? this should reproduce it every time in shrike with ignored packages remove the .rhn-applet.cache _before_ startx --> no, only sometimes !!
boot shrike in init 3 procedure: $ cd ~ $ mv .rhn-applet.cache old-cache $ startx - voila "1 pixel wide applet icon" (only sometimes)
or
$ echo "" > .rhn-applet.cache $ startx - voila "1 pixel wide applet icon" (only sometimes)
logout
$ mv old-cache .rhn-applet.cache $ startx - rhn-applet is ok
ok, .rhn-applet.cache will be new generated from time to time !
perhaps in this way ...
init3, tty*
# chmod 000 ~user/.rhn-applet.cache # chown root.root ~user/.rhn-applet.cache $ startx - voila "1 pixel wide applet icon" (but only sometimes)
it must be magic :-(
but speed is not magic,
its mostly reproducable short after the reboot but later its mostly not reproducable with or without .rhn-applet.cache could it be that rhn-applet do not need every startx the .rhn-applet.cache ?
network should be no problem (dsl-flatrate)
# grep GATE /etc/sysconfig/network GATEWAY=192.168.101.1 #GATEWAY=192.168.101.100 GATEWAYDEV=eth0
# tcpdump -i eth0 | grep rhn tcpdump: listening on eth0 01:01:29.772756 192.168.101.10.33024 > xmlrpc.rhn.redhat.com.https: S 1170839803:1170839803(0) win 5840 <mss 1460,sackOK,timestamp 649131 0,nop,wscale 0> (DF) 01:01:29.963672 xmlrpc.rhn.redhat.com.https > 192.168.101.10.33024: S 4213234648:4213234648(0) ack 1170839804 win 5840 <mss 1380,nop,wscale 0> (DF) 01:01:29.963728 192.168.101.10.33024 > xmlrpc.rhn.redhat.com.https: . ack 1 win 5840 (DF) 01:01:29.964731 192.168.101.10.33024 > xmlrpc.rhn.redhat.com.https: P 1:125(124) ack 1 win 5840 (DF) 01:01:30.163389 xmlrpc.rhn.redhat.com.https > 192.168.101.10.33024: . ack 125 win 5840 (DF) 01:01:30.181739 xmlrpc.rhn.redhat.com.https > 192.168.101.10.33024: P 1:1214(1213) ack 125 win 5840 (DF)
It is 27 bytes, and I sent it to you as a separate email from my Severn box. I hope I sent it to you correctly. I can't figure out how to get Evolution 1.4 to attach a file that has a leading dot '.', and this led me into a very inexpert session with mutt.
Thanks
Bob Cochran
On Sun, 2003-08-03 at 17:17, Daniel Veillard wrote:
On Sun, Aug 03, 2003 at 05:12:39PM -0400, Robert L Cochran wrote:
Yes I do, dated July 28 at time 21:20, permissions -rw-rw-r--, file size 27
Hum, 27 bytes or 27 KB ? In the first case could you send me a copy in attachment, this is not normal and could explain some of the problems encountered !
Daniel
Robert L Cochran wrote:
It is 27 bytes, and I sent it to you as a separate email from my Severn box. I hope I sent it to you correctly. I can't figure out how to get Evolution 1.4 to attach a file that has a leading dot '.', and this led me into a very inexpert session with mutt.
"mutt", "pine", "mail", ... :-)
$ mutt [m] = message to: subject: here you will be in vi [i] edit your text [esc][:][x] or [esc][w][q]
[a] = attach ".rhn-applet.cache" or [?] = list [m] = mask, change this to ".rhn*" choose the file [enter] [y] = send [q] = quitt
On Sun, Aug 03, 2003 at 09:52:28PM -0400, Robert L Cochran wrote:
It is 27 bytes, and I sent it to you as a separate email from my Severn box. I hope I sent it to you correctly. I can't figure out how to get Evolution 1.4 to attach a file that has a leading dot '.', and this led me into a very inexpert session with mutt.
I got it, will try to reproduce this today. Still I puzzled, I don't see anything in the code which could explain why the cache state can influence the rendering, *except* if it is a bug raised under load condition, then rebuilding the cache generates a lot of I/O though the rpm database, which added to the load associated to starting the desktop might create the conditions to raise that problem. If it's a race condition in the inter-process communication interface between the applet and the applet container running in the toolbar then having a lot of I/O might generate proper condition for the problem. It would be interesting to see if you get the same problem with little load, for example once in the session, assuming the applet didn't display correctly, what happen if you kill the applet and restart it with "killall rhn-applet-gui ; rhn-applet-gui &" is the display still broken ?
Daniel
I have the next step.. a missing rhn. The application is running, but there is absolutely no icon showing up on the bar. I have looked for any file in my .??* that mentions rhn and removed them. I cleaned up as much as I can, rebooted, relogged in and ran rhn-applet-gui. It says it is running, but it does not do anything the panel. It doesnt write a .rhn-cache either... just stis in a poll/gettimeofdaty/ioctl/write loop according to strace.
It seems to be reading stuff from the network, taking up the cpu and growing in size.. but not allocating any window space. Dont know how to debug it much furhter.
On Mon, 2003-08-04 at 09:07, Daniel Veillard wrote:
On Sun, Aug 03, 2003 at 09:52:28PM -0400, Robert L Cochran wrote:
It is 27 bytes, and I sent it to you as a separate email from my Severn box. I hope I sent it to you correctly. I can't figure out how to get Evolution 1.4 to attach a file that has a leading dot '.', and this led me into a very inexpert session with mutt.
I got it, will try to reproduce this today. Still I puzzled, I don't see anything in the code which could explain why the cache state can influence the rendering, *except* if it is a bug raised under load condition, then rebuilding the cache generates a lot of I/O though the rpm database, which added to the load associated to starting the desktop might create the conditions to raise that problem. If it's a race condition in the inter-process communication interface between the applet and the applet container running in the toolbar then having a lot of I/O might generate proper condition for the problem. It would be interesting to see if you get the same problem with little load, for example once in the session, assuming the applet didn't display correctly, what happen if you kill the applet and restart it with "killall rhn-applet-gui ; rhn-applet-gui &" is the display still broken ?
Daniel
On Mon, Aug 04, 2003 at 10:36:14AM -0600, Stephen Smoogen wrote:
I have the next step.. a missing rhn. The application is running, but there is absolutely no icon showing up on the bar. I have looked for any file in my .??* that mentions rhn and removed them. I cleaned up as much as I can, rebooted, relogged in and ran rhn-applet-gui. It says it is running, but it does not do anything the panel. It doesnt write a .rhn-cache either... just stis in a poll/gettimeofdaty/ioctl/write loop according to strace.
It seems to be reading stuff from the network, taking up the cpu and growing in size.. but not allocating any window space. Dont know how to debug it much furhter.
Is there another application using the RPM database in a continuous use ? That's my bet, the applet ways for the RPM DB to stop being under activity to process further.
Daniel
Hmmm doesnt look to be
[root@smoogen1 smoogen]# lsof | grep rpm rhn-apple 5077 smoogen mem REG 9,2 895000 498767 /usr/lib/librpmdb-4.2.so rhn-apple 5077 smoogen mem REG 9,2 214008 498768 /usr/lib/librpmio-4.2.so rhn-apple 5077 smoogen mem REG 9,2 304832 498765 /usr/lib/librpm-4.2.so rhn-apple 5077 smoogen mem REG 9,2 93856 519675 /usr/lib/python2.2/site-packages/rpmmodule.so
Unless I need to look at something else.
On Mon, 2003-08-04 at 10:43, Daniel Veillard wrote:
On Mon, Aug 04, 2003 at 10:36:14AM -0600, Stephen Smoogen wrote:
I have the next step.. a missing rhn. The application is running, but there is absolutely no icon showing up on the bar. I have looked for any file in my .??* that mentions rhn and removed them. I cleaned up as much as I can, rebooted, relogged in and ran rhn-applet-gui. It says it is running, but it does not do anything the panel. It doesnt write a .rhn-cache either... just stis in a poll/gettimeofdaty/ioctl/write loop according to strace.
It seems to be reading stuff from the network, taking up the cpu and growing in size.. but not allocating any window space. Dont know how to debug it much furhter.
Is there another application using the RPM database in a continuous use ? That's my bet, the applet ways for the RPM DB to stop being under activity to process further.
Daniel
Well that's the only way I can think the applet going into a stat() / gettimeofday() / select() loop without reading or writing anything... no idea.
Daniel
On Mon, Aug 04, 2003 at 10:49:07AM -0600, Stephen Smoogen wrote:
Hmmm doesnt look to be
[...]
Unless I need to look at something else.
It seems to be reading stuff from the network, taking up the cpu and growing in size.. but not allocating any window space. Dont know how to debug it much furhter.
Is there another application using the RPM database in a continuous use ? That's my bet, the applet ways for the RPM DB to stop being under activity to process further.
Daniel
On Sunday 03 August 2003 21:52, Robert L Cochran Robert L Cochran cochranb@speakeasy.net wrote:
I can't figure out how to get Evolution 1.4 to attach a file that has a leading dot '.', and this led me into a very inexpert session with mutt.
... just a suggestion: the leading dot indicates it is a hidden file or folder. You could have made a copy of the file and renamed it. I.e. *removed* the leading dot so instead of ".rhn applet cache" you would have "rhn applet cache". IMVHO, this is why mutt couldn't "see" the file to attach it.
HTH & cheers,
Elton ;-)
Hi Elton,
Mutt sees files with a leading dot just fine. But Evolution doesn't for some reason. I know I could have renamed the file, but I hate doing that because later I forget why I renamed it and hence what it is there for. I could have renamed it, sent it to Daniel, and then immediately deleted it, true. I'm not making much sense. I resent Evolution's not being able to "see" and attach these files -- it's a sign of a poorly programmed application.
Bob Cochran Greenbelt, Maryland, USA
On Mon, 2003-08-04 at 13:01, Elton Woo wrote:
On Sunday 03 August 2003 21:52, Robert L Cochran Robert L Cochran cochranb@speakeasy.net wrote:
I can't figure out how to get Evolution 1.4 to attach a file that has a leading dot '.', and this led me into a very inexpert session with mutt.
... just a suggestion: the leading dot indicates it is a hidden file or folder. You could have made a copy of the file and renamed it. I.e. *removed* the leading dot so instead of ".rhn applet cache" you would have "rhn applet cache". IMVHO, this is why mutt couldn't "see" the file to attach it.
HTH & cheers,
Elton ;-)
It is very interesting but today my icon is at it's normal size and is working just great.
Theory: the application listens for signals from Mother (home base, that is, RHN) and destroys the icon on command. We already know it 'phones home' to check for update availability.
Theory: The icon is destroyed when RHN has a problem of some sort.
Bob Cochran
On Mon, 2003-08-04 at 12:56, Daniel Veillard wrote:
Well that's the only way I can think the applet going into a stat() / gettimeofday() / select() loop without reading or writing anything... no idea.
Daniel
On Mon, Aug 04, 2003 at 10:49:07AM -0600, Stephen Smoogen wrote:
Hmmm doesnt look to be
[...]
Unless I need to look at something else.
It seems to be reading stuff from the network, taking up the cpu and growing in size.. but not allocating any window space. Dont know how to debug it much furhter.
Is there another application using the RPM database in a continuous use ? That's my bet, the applet ways for the RPM DB to stop being under activity to process further.
Daniel
On Monday 04 August 2003 13:22, Robert L Cochran Robert L Cochran cochranb@speakeasy.net wrote:
Mutt sees files with a leading dot just fine. But Evolution doesn't for some reason. I know I could have renamed the file, but I hate doing that because later I forget why I renamed it and hence what it is there for.
Well, removing the leading dot, is not a big name change, but I see your point...
I could have renamed it, sent it to Daniel, and then immediately deleted it, true. I'm not making much sense. I resent Evolution's not being able
No. You *are* making sense, and you have a very valid point.
to "see" and attach these files -- it's a sign of a poorly programmed application.
I would suggest reporting this to the mutt developers.
Elton ;-)
I was wrong about no writing.. here is what it says..
write(10, "5\20\4\0\5\35\340\1\204\0\340\1\26\0\26\0007\34\6\0\6\35"..., 292) = 292 ioctl(10, FIONREAD, [0]) = 0 gettimeofday({1060014706, 94176}, NULL) = 0 poll([{fd=11, events=POLLIN}, {fd=10, events=POLLIN}, {fd=3, events=POLLIN}, {fd=6, events=POLLIN|POLLPRI}, {fd=9, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN|POLLPRI}, {fd=5, events=POLLIN|POLLPRI}], 7, 43) = 0 gettimeofday({1060014706, 151938}, NULL) = 0 ioctl(10, FIONREAD, [0]) = 0 gettimeofday({1060014706, 152490}, NULL) = 0 poll([{fd=11, events=POLLIN}, {fd=10, events=POLLIN}, {fd=3, events=POLLIN}, {fd=6, events=POLLIN|POLLPRI}, {fd=9, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN|POLLPRI}, {fd=5, events=POLLIN|POLLPRI}], 7, 0) = 0 gettimeofday({1060014706, 152921}, NULL) = 0 write(10, "5\20\4\0\t\35\340\1\204\0\340\1\26\0\26\0007\34\6\0\n\35"..., 292) = 292 ioctl(10, FIONREAD, [0]) = 0 gettimeofday({1060014706, 154229}, NULL) = 0 poll([{fd=11, events=POLLIN}, {fd=10, events=POLLIN}, {fd=3, events=POLLIN}, {fd=6, events=POLLIN|POLLPRI}, {fd=9, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN|POLLPRI}, {fd=5, events=POLLIN|POLLPRI}], 7, 37) = 0 gettimeofday({1060014706, 211196}, NULL) = 0 ioctl(10, FIONREAD, [0]) = 0 gettimeofday({1060014706, 211787}, NULL) = 0
On Mon, 2003-08-04 at 10:56, Daniel Veillard wrote:
Well that's the only way I can think the applet going into a stat() / gettimeofday() / select() loop without reading or writing anything... no idea.
Daniel
On Mon, Aug 04, 2003 at 10:49:07AM -0600, Stephen Smoogen wrote:
Hmmm doesnt look to be
[...]
Unless I need to look at something else.
It seems to be reading stuff from the network, taking up the cpu and growing in size.. but not allocating any window space. Dont know how to debug it much furhter.
Is there another application using the RPM database in a continuous use ? That's my bet, the applet ways for the RPM DB to stop being under activity to process further.
Daniel
On Mon, Aug 04, 2003 at 12:50:07PM -0600, Stephen Smoogen wrote:
I was wrong about no writing.. here is what it says..
write(10, "5\20\4\0\5\35\340\1\204\0\340\1\26\0\26\0007\34\6\0\6\35"..., 292) = 292 ioctl(10, FIONREAD, [0]) = 0 gettimeofday({1060014706, 94176}, NULL) = 0 poll([{fd=11, events=POLLIN}, {fd=10, events=POLLIN}, {fd=3, events=POLLIN}, {fd=6, events=POLLIN|POLLPRI}, {fd=9, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN|POLLPRI}, {fd=5, events=POLLIN|POLLPRI}], 7, 43) = 0 gettimeofday({1060014706, 151938}, NULL) = 0 ioctl(10, FIONREAD, [0]) = 0 gettimeofday({1060014706, 152490}, NULL) = 0 poll([{fd=11, events=POLLIN}, {fd=10, events=POLLIN}, {fd=3, events=POLLIN}, {fd=6, events=POLLIN|POLLPRI}, {fd=9, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN|POLLPRI}, {fd=5, events=POLLIN|POLLPRI}], 7, 0) = 0 gettimeofday({1060014706, 152921}, NULL) = 0 write(10, "5\20\4\0\t\35\340\1\204\0\340\1\26\0\26\0007\34\6\0\n\35"..., 292) = 292 ioctl(10, FIONREAD, [0]) = 0 gettimeofday({1060014706, 154229}, NULL) = 0 poll([{fd=11, events=POLLIN}, {fd=10, events=POLLIN}, {fd=3, events=POLLIN}, {fd=6, events=POLLIN|POLLPRI}, {fd=9, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN|POLLPRI}, {fd=5, events=POLLIN|POLLPRI}], 7, 37) = 0 gettimeofday({1060014706, 211196}, NULL) = 0 ioctl(10, FIONREAD, [0]) = 0 gettimeofday({1060014706, 211787}, NULL) = 0
could be writes to the XWindows socket though it's kinda strange there are no reads ... A bit strange though to have fd=10 for that socket I would expect a lower number.
Daniel
On Mon, 2003-08-04 at 13:22, Robert L Cochran wrote:
Hi Elton,
Mutt sees files with a leading dot just fine. But Evolution doesn't for some reason. I know I could have renamed the file, but I hate doing that because later I forget why I renamed it and hence what it is there for. I could have renamed it, sent it to Daniel, and then immediately deleted it, true. I'm not making much sense. I resent Evolution's not being able to "see" and attach these files -- it's a sign of a poorly programmed application.
A) It's the GTK+ file selector, not Evolution
B) If you type the name into file selector explicitely it will work fine.
C) Rather more obscurely, .<TAB> will show all files starting with .
D) Yes, we know that the current GTK+ file selector has a poor UI. GTK+-2.4 will have an entirely different and opefully better widget.
Regards, Owen
Is there any X commands etc that I can use to further debug this?
In the large strace file I have open("/usr/share/locale/en/LC_MESSAGES/gtk20.mo", O_RDONLY) = -1 ENOENT (No such file or directory) uname({sys="Linux", node="smoogen1.lanl.gov", ...}) = 0 socket(PF_UNIX, SOCK_STREAM, 0) = 10 uname({sys="Linux", node="smoogen1.lanl.gov", ...}) = 0 uname({sys="Linux", node="smoogen1.lanl.gov", ...}) = 0 connect(10, {sa_family=AF_UNIX, path="/tmp/.X11-unix/X0"}, 19) = 0 uname({sys="Linux", node="smoogen1.lanl.gov", ...}) = 0 fcntl64(10, F_SETFD, FD_CLOEXEC) = 0
On Mon, 2003-08-04 at 13:08, Daniel Veillard wrote:
On Mon, Aug 04, 2003 at 12:50:07PM -0600, Stephen Smoogen wrote:
I was wrong about no writing.. here is what it says..
write(10, "5\20\4\0\5\35\340\1\204\0\340\1\26\0\26\0007\34\6\0\6\35"..., 292) = 292 ioctl(10, FIONREAD, [0]) = 0 gettimeofday({1060014706, 94176}, NULL) = 0 poll([{fd=11, events=POLLIN}, {fd=10, events=POLLIN}, {fd=3, events=POLLIN}, {fd=6, events=POLLIN|POLLPRI}, {fd=9, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN|POLLPRI}, {fd=5, events=POLLIN|POLLPRI}], 7, 43) = 0 gettimeofday({1060014706, 151938}, NULL) = 0 ioctl(10, FIONREAD, [0]) = 0 gettimeofday({1060014706, 152490}, NULL) = 0 poll([{fd=11, events=POLLIN}, {fd=10, events=POLLIN}, {fd=3, events=POLLIN}, {fd=6, events=POLLIN|POLLPRI}, {fd=9, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN|POLLPRI}, {fd=5, events=POLLIN|POLLPRI}], 7, 0) = 0 gettimeofday({1060014706, 152921}, NULL) = 0 write(10, "5\20\4\0\t\35\340\1\204\0\340\1\26\0\26\0007\34\6\0\n\35"..., 292) = 292 ioctl(10, FIONREAD, [0]) = 0 gettimeofday({1060014706, 154229}, NULL) = 0 poll([{fd=11, events=POLLIN}, {fd=10, events=POLLIN}, {fd=3, events=POLLIN}, {fd=6, events=POLLIN|POLLPRI}, {fd=9, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN|POLLPRI}, {fd=5, events=POLLIN|POLLPRI}], 7, 37) = 0 gettimeofday({1060014706, 211196}, NULL) = 0 ioctl(10, FIONREAD, [0]) = 0 gettimeofday({1060014706, 211787}, NULL) = 0
could be writes to the XWindows socket though it's kinda strange there are no reads ... A bit strange though to have fd=10 for that socket I would expect a lower number.
Daniel
Thanks a lot, Owen, for setting me straight!
Bob Cochran
On Mon, 2003-08-04 at 15:13, Owen Taylor wrote:
On Mon, 2003-08-04 at 13:22, Robert L Cochran wrote:
Hi Elton,
Mutt sees files with a leading dot just fine. But Evolution doesn't for some reason. I know I could have renamed the file, but I hate doing that because later I forget why I renamed it and hence what it is there for. I could have renamed it, sent it to Daniel, and then immediately deleted it, true. I'm not making much sense. I resent Evolution's not being able to "see" and attach these files -- it's a sign of a poorly programmed application.
A) It's the GTK+ file selector, not Evolution
B) If you type the name into file selector explicitely it will work fine.
C) Rather more obscurely, .<TAB> will show all files starting with .
D) Yes, we know that the current GTK+ file selector has a poor UI. GTK+-2.4 will have an entirely different and opefully better widget.
Regards, Owen
On Mon, 2003-08-04 at 08:07, Daniel Veillard wrote:
On Sun, Aug 03, 2003 at 09:52:28PM -0400, Robert L Cochran wrote:
It is 27 bytes, and I sent it to you as a separate email from my Severn box. I hope I sent it to you correctly. I can't figure out how to get Evolution 1.4 to attach a file that has a leading dot '.', and this led me into a very inexpert session with mutt.
I got it, will try to reproduce this today. Still I puzzled, I don't see anything in the code which could explain why the cache state can influence the rendering, *except* if it is a bug raised under load condition, then rebuilding the cache generates a lot of I/O though the rpm database, which added to the load associated to starting the desktop might create the conditions to raise that problem. If it's a race condition in the inter-process communication interface between the applet and the applet container running in the toolbar then having a lot of I/O might generate proper condition for the problem. It would be interesting to see if you get the same problem with little load, for example once in the session, assuming the applet didn't display correctly, what happen if you kill the applet and restart it with "killall rhn-applet-gui ; rhn-applet-gui &" is the display still broken ?
I also get the broken rhn applet display. Since I have only installed severn today I cannot say if it is intermittent or not. I have a .rhn-applet.cache file, which has 644 permissions and is of size 243689.
Running "killall rhn-applet-gui ; rhn-applet-gui &" did fix the applet.
I don't seem to be able to get it to break again tho'; I've only tried a couple of things; logging out/in and rebooting.
This is on a Dell Optiplex GXa 266Mhz processor / 64Mb memory.
BTW, this also happens to me on my Shrike box at home a 333Mhz/192Mb system. There is is intermittent.
On Wed, Aug 06, 2003 at 03:56:19PM -0700, Christian Thibodeau wrote:
On Mon, 2003-08-04 at 08:07, Daniel Veillard wrote:
I got it, will try to reproduce this today. Still I puzzled, I don't see anything in the code which could explain why the cache state can influence the rendering, *except* if it is a bug raised under load condition, then rebuilding the cache generates a lot of I/O though the rpm database, which added to the load associated to starting the desktop might create the conditions to raise that problem. If it's a race condition in the inter-process communication interface between the applet and the applet container running in the toolbar then having a lot of I/O might generate proper condition for the problem. It would be interesting to see if you get the same problem with little load, for example once in the session, assuming the applet didn't display correctly, what happen if you kill the applet and restart it with "killall rhn-applet-gui ; rhn-applet-gui &" is the display still broken ?
I also get the broken rhn applet display. Since I have only installed severn today I cannot say if it is intermittent or not. I have a .rhn-applet.cache file, which has 644 permissions and is of size 243689.
Running "killall rhn-applet-gui ; rhn-applet-gui &" did fix the applet.
I don't seem to be able to get it to break again tho'; I've only tried a couple of things; logging out/in and rebooting.
This is on a Dell Optiplex GXa 266Mhz processor / 64Mb memory.
BTW, this also happens to me on my Shrike box at home a 333Mhz/192Mb system. There is is intermittent.
This tend to confirm my hypothesis that this is related to load, especially if rebuilding the cache on a first start, a relatively slow machine or low memory conditions might exacerbate the problem ...
thanks for the report !
Daniel
tor 2003-08-07 klockan 12.20 skrev Daniel Veillard:
This tend to confirm my hypothesis that this is related to load, especially if rebuilding the cache on a first start, a relatively slow machine or low memory conditions might exacerbate the problem ...
thanks for the report !
Daniel
When i start my computer and log in to the Gnome desktop i can see this one pixel-wide RHN icon for about a second or two. I have an P3-500 with 512 mb ram. I installed everything from the BETA and have not checked what is starting and what is not, so i might have lots of stuff starting - that is, heavy load. So i guess this might also confirm your hypothesis? For me the icon gets the right size after that second or two though. But also, i do recall seeing the one pixel-size icon for a whole session rather than just a second while starting gnome.
On Sun, Aug 10, 2003 at 09:27:46PM +0200, Kent Nyberg wrote:
tor 2003-08-07 klockan 12.20 skrev Daniel Veillard:
This tend to confirm my hypothesis that this is related to load, especially if rebuilding the cache on a first start, a relatively slow machine or low memory conditions might exacerbate the problem ...
thanks for the report !
Daniel
When i start my computer and log in to the Gnome desktop i can see this one pixel-wide RHN icon for about a second or two. I have an P3-500 with 512 mb ram. I installed everything from the BETA and have not checked what is starting and what is not, so i might have lots of stuff starting - that is, heavy load. So i guess this might also confirm your hypothesis? For me the icon gets the right size after that second or two though.
Hum, interesting ...
But also, i do recall seeing the one pixel-size icon for a whole session rather than just a second while starting gnome.
At the moment the only idea I can get to work around this would be to block the program until load goes back to some "normal" state, but I really can't accept this as a decent solution, I'm afraid it would open the door to more insane problems, sigh ...
Daniel
-
Christian Thibodeau -
Daniel Veillard -
Elton Woo -
Féliciano Matias -
Kent Nyberg -
Owen Taylor -
Robert L Cochran -
shrek-m＠gmx.de -
Stephen Smoogen