rp5 watch eating up disk space
97-109-107 opened this issue · comments
Whenever I run my sketch (http://pastebin.com/60v0EpfY) some process starts writing to the hard drive, and I haven't specified any parts of my code to perform any writes. Upon closing the process, or it crashing, the hard drive space isn't cleared. I'm still trying to figure this out, but it looks like it ate up around 1GB over the course of 3 days of debugging. Whatever it is writing, it isn't located neither in /tmp/ not ~/tmp. I'd appreciate any help in locating the files it might have written. So far I used du with watch to monitor, as well as iotop and lsof. The output of lsof is here http://pastebin.com/raw.php?i=YrLPsUqU), stripped down to only files touched by the java process.
Any hints in appreciated.
Which version of ruby-processing are you using? By the way 'watch' is not really suitable for anything other than fairly simple sketches so you should use 'run' instead...
Version: 1.0.11
I just tried to compare run and watch. I'm not entirely convinced if I see a diffrence, but it seems so.
Correct me if I'm wrong but I don't think those sketches are recursive to one another.
Is it possible that java/jruby created some cache outside of /tmp? If so, any tips on finding it? While running this sketch I occasianally had a heap overflow and com.kenai.jffi.Foreign$InValidInstanceHolder.getForeign(Foreign.java:90) reporting insufficent space left on device.
Watch instead of run is something else to go wrong at the very least (you might be generating multiple instance of PApplet, that don't get disposed off correctly, try with a simple sketch and two Applets).
However perhaps your issue is also something to do with JRuby-1.6.7 if so, it is nothing I can help with?
However it may not be 'recursive' but firing up two instances of Sketch in one thread does seem a bit odd (bare sketches are called Sketch and I'm preferring bare Sketches in my development version so that was my initial reaction),,,
I think you need to find the simplest setup that reproduces the problem, to make any progress. Thereafter may'be the jruby boys can help.
By the way I belatedly replied to your issue with using ruby libraries in another thread, I guess that did solve that problem, and that's why we are here no?
Thanks for those replies in that thread. I didn't go for a gem in this case, because I want to rely on rp5 wrapping ability. The link to the blogpost seemed to be the most clear.
After rigourous testing it seems that it is the open function that cause the leak. I will be looking into it further, but this, to me at least, renders it a non rp5 issue.