Description of problem: When system-logviewer loads (and subsequently when using the program) an excessive amount of swap activity occurs with high cpu usage (maxed). Before the logviewer window is displayed over 400Mb of swap space has been claimed by python. After using the viewer for a short period another block of swapping activity locks up the system so X does not even refresh. Occassionally the logviewer cpu usage will cease and it will function normally for a short period before cpu usage again maxes out. Attaching to python from a vt and killing the process allowed X to refresh again, system running fine. Version-Release number of selected component (if applicable): system-logviewer-0.9.11-1 gtk2-devel-2.4.10-7 How reproducible: Consistent. Repeated but only 3 times so far. Actual results: System becomes unusable while attempting to view logs. Expected results: Logviewer should display all logfile entries without consuming large amounts of swap space. Additional info: system-logviewer was started from a root (su -) logged in terminal in a normal user X session. backtrace of python during this issue is attached It appears to be stuck in a library call from gtk2-devel. /usr/lib/libgtk-x11-2.0.so.0 -> libgtk-x11-2.0.so.0.400.10
Created attachment 104967 [details] backtrace of python running system-logviewer
This backtrace is not taken while the system is fully hung, I cannot bring it to a complete hang state, but the backtrace does change at different times while continuing under gdb. It has been deeper, into xft calls but this so if this is not very helpful I'd appreciate hints how to recover something that will help more. I am new to fairly new to gdb.
What is your refresh time set too in Preferences? Which log are you viewing when this occurs. What is the actuall log file size: ls -al /var/log/ Please could you show the memory usage via vmstat or top for system-logviewer. For more detailed X resource usage can you do (yum install xrestop): xrestop -b | grep -A 14 system-logviewer Whilst memory use is high.
I apologize for the delay in getting back to this one. I had the requested output but cannot find it.. and cannot reproduce the behavior anymore. I will make another attempt to push the program and see what happens, but (see below) I think this may have been a problem "between chair and keyboard". It is a shame Bugzilla doesn't have a resolution to fit that. What I did find out was that I had one messages logfile (I think it was rotated and gzip'd but not positive now) that was 90+ Mb of runaway selinux spam. The refresh being used was default, which appears to be 30secs. That might create an unreasonable load on parsing the logs. Perhaps logs of 'larger' size should not refresh, although the initial load would still take a long time. If this was simply a problem of my one large logfile it made the system unusable while the process was still running, and that should be avoided if possible.
system-logviewer has been removed from core.