Bug 72155

We do take bug reports seriously.  We're not able to always fix
all bugs that are reported, but we try to fix as many as we can.

It isn't completely clear what you mean by "windows deteriorated"
above.  Could you explain that in more detail?  If you could
produce a screenshot of this, and attach it to the bug report,
that would perhaps help also.  My suspicion is that you're
experiencing some form of screen corruption.

What video card are you using?  It is possible it could be video
driver related.

It's interesting to think of screen corruption as a cause but it's my fault for
using the terms `window deterioration'. I can readily understand where video is
the immediate interpretation. 
The video `card' on the gigabyte board is Nvidia with 64mb.

I should have explained that the deterioration I was experiencing was within the
window and did not relate to the quality of the screen but to the deterioration
and behavior of the applications such as the gnome file manager [nautilus].

The deterioration of the window relates to the fact that the file manager would:

1 - work fine for a while [days, maybe even weeks] only occasionally crashing;
2 - close/crash when directories/files were dragged/trashed more frequently;
3 - it could be re-activated/opened after a crash and work for a while, then;
4 - it could no loger be opened;
5 - the other icons would also refuse to function.

This last time, as root,I had dragged some errata which I had downloaded, as
scn, in /home/scn/ ...to /misc/rpm/ ...

I then tried, as root, to open the terminal window to rpm the errata, but couldn't.
I rebooted to kernel panic.

Cause: To me it seems that the dragging function disrupted and corrupted areas.
Effect: leading to kernel panic.

I am trying to avoid using the file-manager to move/drag but it is difficult and
I wonder it the deterioration has a cumulative effect? as it seems to get worse
with time.

This was not my first kernel panic - I just hope it will be my last.

In kernel panic situation I had been also been working with the preferences on
Mozilla. Mozilla does not take multiple changes and refuses to close the
preferences folder. I then thought it was the principal culprit  and reported to
bugzilla but I don't think it was ever followed up.

I now feel that the file manager is the main culprit; maybe Mozilla is a
contributing factor but I don't really know.

I'll be glad to cooperate.

Can you please attach your X configuration file /etc/X11/XF86Config-4,
your X log file /var/log/XFree86.0.log, your kernel log /var/log/messages
and also the output of the following commands:

uname -a
lsmod

Run the following command, and attach the resulting file "rpm.log"

rpm -qa | sort > rpm.log

Here are the files requested. I think I can only upload one at a time.

I noticed, in /home/scn that I was crashing the file manager when dragging empty
directories to trash.
I tend to use empty folders as `notes' within another directory and as I
can'tdon't-know how to change the folder title I drag it to trash and open
another one.

I chose 24 colors for the Xwindow & 1024x780 [I think].

Created attachment 72806 [details]
rpm -qa file

Created attachment 72807 [details]
lsmod file

Created attachment 72808 [details]
/etc/X11/XF86Config-4

Created attachment 72809 [details]
/var/log/XFree86.0.log

Created attachment 72810 [details]
/var/log/messages

I download the rpm from rhn as they are posted by rhn and then apply them
While `rpm-ing'[-Fvh], before and also most recently on re-installation a few
days ago, I had noticed the some rpm resulted in a multitude of `conflict' messages.

I posted a couple of questions to the non-bugzilla support group but never
received a real reply.
The rpms in question are particularly the glibc and openssl series:
 - 116-03 - glibc-2.2.5-36
 - 139-10 - glibc-2.2.5-37
 - 166-07 - glibc-2.2.5-39
one of their very many conflict messages was: 
/usr/lib/gconv/UTF-16.50 conflicts between attempted installs of glibc-2.2.5-36
and glibc-2.2.5-36 
[this looks to me as the same file which presumably just got installed!].

and also the openssl series:
 - 155-11 - openssl-0.9.6b-24
 - 160-21 - openssl-0.9.6b-28

All the messages were essentially similar and involved the files to be installed.

I don't know if these messages indicate corruption? but they puzzle me as they
reveal an aberrant behavior.

Most of the other rpms installed with no problem except for those which never
seemed to install with -Fvh:
- 051-16 - squid
- 070-08 - modpython
- 088-06 - ethereal
- 095-08 - minichinput  -  I'm not quite sure why rhn included this errata.
- 099-04 - mailman
I am tempted to install these last rpms with -ivh?

I was wondering if there was a practical way to measure and record memory
leakage as folders/files are dragged/trashed?
Does rh7.3 have an error alert which would indicate irregular behavior by an
application rather than crashing.
Os/2 crashes with a Trap D [or other] error msg. but will usually recover on reboot.

I am available.
You can also reach me @ 1212.794.0058

FYI
A similar kernel panic occurred in rh7.2 and I left that hd as is and use os2
which is also on it.
If you think it might provide insight[s] let me know how and I'll try to get it.

I am maybe becoming paranoid but I sense a deterioration in the behavior of both
Mozilla and the file manager [Nautilus] yesterday evening.
Mozilla email definition windows had trouble closing - I had to log out and it
restored itself.

I find it hard to believe I'm doing something that unusual that it has not
happened many times before.

If you have any words of wisdom or needs for file[s] let me know.

thanks

This bug report is horked.  It has:

Bug 72155 depends on:71880

and

Bug 72155 blocks:69639

When I try to add any comment to the bug report, bugzilla freaks right out,
and gives me:

       Dependency loop detected!

       The change you are making to dependencies has caused a
       circular dependency chain.

       Please press Back and try again.

However I haven't made _ANY_ changes other than adding a comment.
As such, I am removing the bogus dependancies from this report as
they aren't particularly that useful anyway.  Neither bug is
dependant in any way on the others being fixed first.

Please do not add bogus dependancy information to bug reports.

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

Please attach a screen shot of the corrupted video.

Created attachment 74725 [details]
screenshot of nautilus

Created attachment 74726 [details]
nautilus with jpg

Created attachment 74727 [details]
nautilus in .jpg

Created attachment 74729 [details]
nautilus - jpg

Created attachment 74730 [details]
nautilu - jpg

ALERT

SYSTEM IS DEGRADING AND HEADING FOR KERNEL PANIC.

NAUTILUS IS non functional in /home/scn
fstab lost a line affecting the Orb 2.2 gig removable hard drive:
/dev/sda1   /mnt/sda   etc ...

I will try to arrest this degradation by going to 16 from 24 [if I can] and see
if that restores the screen

I went in as root whose window worked with no problems and called Xconfigurator.

Chose the noprobe then the monitor, video card and 16 plus 1024x768 [I think].
Well, in checking the combination it froze and I had to reboot.

I presumed that rebooting canceled the change from 24 to 16 but I don't know how
to easily check the status of the video environment without going to its
XF86Config file which seems to indicate that it is running at 16.

Could that have been the problem? 
or is that only a temporary reprieve?
why the slow deterioration?
why did the many re-installations I had to make accept the 24 and show the
message while it didn't seem to accept the 16 today and froze?

Let me know your opinion and if you need anything else.

thanks

The screenshots that you have provided show to me that this is not
actually an XFree86 bug/problem but rather is most likely a nautilus
bug.

What is happening is nautilus is screwing up somewhere, the process is
spinning off into deadlock, and the graphics do not get updated.  The
state of the nautilus window is then in disarray.  Most likely, if you
look at the output of the "top" command, you'll see your nautilus
process(es) consuming a large amount of CPU resources in the hung
spinning state.

Reassigning to nautilus component.

I am both happy and unhappy at the reassignment to Nautilus.
Happy to feel that we are narrowing the field to a real culprit; unhappy because
I thought the downgrading from 24 to 16 colordepth was the solution.

As the system, both /root and /home/scn, is responsive to the change to 16 I
think that Nautilus must be having more trouble maintaining its `balance' with
the higher depth of 24.

Am I correct in this assumption and that I should stay at the 24 colordepth?

Until the bug gets resolved I am interested in having a working system so I
would appreciate any and all `words of wisdom' and approaches.

thanks

I would wager that the color depth you are using is completely
irrelevant to the problem.  More likely, any change you see
in changing the color depth is a placebo effect.

The only solution at this point in time is to not use nautilus
at all.

Sorry.

thanks for the words ...
I'm going to keep to a 16 depth hoping that there is a lessening of pressure on
Nautilus. 
I'm surprised that the bug/problem has not surfaced before - I don't consider
myself unique and I encountered this bug in 7.2 which also went to kernel panic.
I reported it then but I don't think anybody took it seriously.
I won't ask for an eta - just 
what happens now?

I can't tell where the problem originates - so for want of a better place let me
lay another one at this portal:
In trying to access mbna.com and capitalone.com - maybe others Mozilla reported
error 8174 - problem with certificate database.
I haven't had any such problem before.
Is it related?

The screenshots show that nautilus is locked up - it's very unlikely to be
related to any problems with the kernel, X server, or mozilla.

The nautilus issue is almost certainly fixed in the latest development version
(aka rawhide) which reworks most of the nautilus code.