Version: unspecified (using KDE 4.7.0) OS: Linux I don't know what error triggered this but something caused ~/.kde4/share/apps/nepomuk/repository/main/data/virtuosobackend/soprano-virtuoso.log to fill up with 878 GIGAbytes of the following message: Reference to page with free remap dp = 17157, remap = 17157 It would be nice if a single error condition that doesn't appear to be affecting the functionality of my desktop in any way didn't cause my hard drive to fill up with nearly 900 GB of a single repeated error message. Reproducible: Didn't try Steps to Reproduce: Unknown Expected Results: Some kind of sanity check that doesn't let the error log grow without bound. # less soprano-virtuoso.log Sat May 07 2011 16:57:37 Virtuoso is already running (pid 3450) Sat May 07 2011 16:57:37 Unable to remove /home/jack/.kde4/share/apps/nepomuk/repository/main/data/virtuosobackend/soprano-virtuoso.lck (No such file or directory) Sun Jun 05 2011 16:23:44 Virtuoso is already running (pid 3454) Sun Jun 05 2011 16:23:45 Unable to remove /home/jack/.kde4/share/apps/nepomuk/repository/main/data/virtuosobackend/soprano-virtuoso.lck (No such file or directory) Mon Jul 04 2011 21:49:11 Virtuoso is already running (pid 3484) Mon Jul 04 2011 21:49:11 Unable to remove /home/jack/.kde4/share/apps/nepomuk/repository/main/data/virtuosobackend/soprano-virtuoso.lck (No such file or directory) Thu Jul 07 2011 21:21:08 Virtuoso is already running (pid 3973) Thu Jul 07 2011 21:21:09 Unable to remove /home/jack/.kde4/share/apps/nepomuk/repository/main/data/virtuosobackend/soprano-virtuoso.lck (No such file or directory) Fri Aug 12 2011 Sun Aug 14 2011 17:38:16 The checkpoint was stopped in the middle of making cpt recov file, recov file ignored 17:38:16 The checkpoint recov file was not complete, hence will roll forward from log. Sat Aug 20 2011 08:32:20 Virtuoso is already running (pid 32317) Sat Aug 20 2011 08:32:21 Unable to remove /home/jack/.kde4/share/apps/nepomuk/repository/main/data/virtuosobackend/soprano-virtuoso.lck (No such file or directory) Sat Aug 20 2011 10:22:58 row with bad kv in RDF_QUAD 10:22:58 GPF: page.c:110 key with bad key version Sat Aug 20 2011 10:35:45 GPF: page.c:119 row length out of range Tue Aug 23 2011 11:47:32 Reference to page with free remap dp = 9280, remap = 9280 11:47:32 Reference to page with free remap dp = 9280, remap = 9280 11:47:32 Reference to page with free remap dp = 9280, remap = 9280 11:47:32 Reference to page with free remap dp = 9280, remap = 9280 11:47:32 Reference to page with free remap dp = 9280, remap = 9280 11:47:32 Reference to page with free remap dp = 9280, remap = 9280 11:47:32 Reference to page with free remap dp = 9280, remap = 9280 11:47:32 Reference to page with free remap dp = 9280, remap = 9280 11:47:32 Reference to page with free remap dp = 9280, remap = 9280 11:47:32 Reference to page with free remap dp = 9280, remap = 9280 11:47:32 Reference to page with free remap dp = 9280, remap = 9280 11:47:32 Reference to page with free remap dp = 9280, remap = 9280 11:47:32 Reference to page with free remap dp = 9280, remap = 9280 11:47:32 Reference to page with free remap dp = 9280, remap = 9280 ...and so on for the next eight hours until my hard drive finally ran out of space.
I can confirm this issue exists in KDE 4.7.3 as distributed in kubuntu 11.10. Twice already I have had to manually delete this file after it filled the disk. This bug should in fact be marked a critical as it results in data loss and system crash (as the only way to regain system function is to invoke a hard crash, reboot to a shell, delete the offending file). As the file exists in the home partition, when the disk fills, open files, including session details normally saved by KDE, firefox etc. all fail to save and are lost. This is in fact two bugs: 1. The fact that this file gets so much log data indicates some underlying problem 2. It should *never* be possible for a log file to fill a disk and render a system unusable
I'm having the same problems on KDE 4.7.3. Right now, directly after login nepomuk starts to write the log message and I am unable to perform any task, anything at all. I also get terminal messages that akonadi fills the memory (out of memory: Kill process 1234 (akonadi_agent_l) score 68 or sacrifice child...). The system is too slow to even execute terminal commands.
Also, soprano fills my .xsession-errors with "the name org.kde.nepomuk.services.nepomukstorage was not provided by any .service files".
I "fixed" this problem on my system by making soprano-virtuoso.log a symlink to /dev/null.
Thank you, I will consider this. Apart from that, is your nepomuk working?
I don't use any of the features of nepomuk so I don't know if it works or not. In fact, I'm trying changing my USE flags right now to see if I can uninstall it from all my computers without adversely affecting the dependencies of other programs.
This seems to be a duplicate of Bug 264465, which is one year old. I have also reported a bug about this today and already marked it as duplicate. This thing caused DATA LOSS for me by filling my encrypted /home/user and killing my kde session, obviously causing an unclean unmount of encryptfs and trashing the documents I was working on. So I suppose to mark this as a major bug and try to resolve it asap, since it exsts for at least a year now. Logs should be regularly flushed or at least limited in size.
I forgot: I am on Kubuntu 11.10 all updated to 4.7.4 and confirm the same problem.
*** This bug has been marked as a duplicate of bug 264465 ***