On 04/25/2012 08:57 AM, David C. Rankin wrote:
For the second attempt working with kwrite, I started it from konsole
so I
could look at the kdDebug output. There was nothing out of the
ordinary.
These crashes have always been difficult for me to isolate. Can
anyone
suggest a test that would help identify the problem. Also, any
reports
confirming this behavior would be helpful.
I just rebuilt tdelibs/tdebase on i686 to confirm - the same crash
occurs and
it is 100% repeatable.
To confirm, all you need to do is open konsole and cat a file or do
something
to give you text to select and copy into kwrite. Then begin selecting
text
(one or two words at a time) in konsole and then middle-mouse paste
into line
1 of kwrite. Continue doing this until you get to the point where the
line
will wrap on the next paste. When you paste the next selection that
would
cause line 1 in kwrite to wrap - the crash will occur.
See example:
http://nirvana.3111skyline.com/dl/dt/trinity/ss/kwrite-i686-crash.jpg
You will then have to 'terminate' kwrite by clicking the close button
and wait
for the 'Terminate' or 'Keep Running' dialog to appear (or 'kill
$(pidof
kwrite)' in konsole)
Any ideas??
When this happens kwrite takes over 80% of CPU, so it looks like something hit a loop and got stuck:
Here is the top output:
16307 david 20 0 45236 19m 15m R 86.9 2.6 1:10.09 kwrite
That's 86.9% of the CPU when kwrite hangs.
Same thing happens in kate. I'll open a new bug with BLOCKER when I get back from lunch :(
I don't see anything in the commits that could cause this. I rebuilt a complete set yesterday but haven't yet tested.
What have you updated on your system that could contribute to this?
I have kept tdelibs and tdebase current because of the testing I have been doing with TSAK/TDM as well as testing Calvin's Mac keyboard shortcut testing. I just tried to duplicate what you describe and kwrite was fine. I can't duplicate the problem. :(
Darrell
I would make absolutely certain that kwrite isn't in D state (via 'ps aux') or similar during the hang before filing a report. TDE applications seem to be somewhat sensitive to swap and disk I/O in general in my experience.
Other than that, the best thing you can do is use gdb to break into kwrite while it is hung and generate a backtrace.
Tim