I am using require 'task' which I believe uses 15!:0. I believe I have switched to using 2!:0 for all my external process needs.
And, of course, the machine is hooked to the internet, which is "unsafe" and relies on people being well behaved or something approximating that. So, yes, I am "doing something unsafe". As for unlikely... I've probably used 25+ years of cpu time on this project. Unlikely is approximately the same thing as inevitable in my book. None of which really helps isolate this particular problem. That said, I can try removing the require 'task' bit. But keep in mind that an experiment costs on the order of 24 hours (and the price of a meal) so if there are other things that seem like "no-brainers" I guess I really ought to consider them. Thanks, -- RaulI On Tue, Aug 19, 2014 at 9:46 AM, Joe Bogner <[email protected]> wrote: > Does it do anything 'unsafe' ? Dynamic memory allocation like memw or 15!:0 > ? I've had crashes, not stalls. The only stalls I've had are on windows due > to deadlocks. As far as I can remember, J is single threaded so a deadlock > seems unlikely unless you have logic that is waiting on some other resource > (socket, file, etc) > > Here's a stackoverflow post that might help with troubleshooting: > http://stackoverflow.com/questions/7785692/program-stalls-during-long-runs > > > On Tue, Aug 19, 2014 at 9:39 AM, Raul Miller <[email protected]> wrote: > >> I have a J program that keeps stalling. My impression is that it has >> been stalling in a random location, but I might be wrong about that. >> >> (1) It takes almost 24 hours to get to the point where it stalls, so >> so far my tests have been few. >> >> (2) When it stalls, it ignores signals for attention, so debugging is hard. >> >> (3) I have had other problems (for example with ioerrors), which also >> makes this difficult to isolate. >> >> (4) Here's a stack trace of my current example of this flaw: >> >> #0 0x00007fb2da462cf9 in ?? () from >> /usr/lib/x86_64-linux-gnu/libj.so.8.0.2 >> #1 0x00007fb2da4626b6 in jtequ () from >> /usr/lib/x86_64-linux-gnu/libj.so.8.0.2 >> #2 0x00007fb2da5278bf in ?? () from >> /usr/lib/x86_64-linux-gnu/libj.so.8.0.2 >> #3 0x00007fb2da514c39 in jtindexofsub () from >> /usr/lib/x86_64-linux-gnu/libj.so.8.0.2 >> #4 0x00007fb2da5165e2 in jtnub () from >> /usr/lib/x86_64-linux-gnu/libj.so.8.0.2 >> >> I am looking for a way of resolving this issue (quickly, because other >> people are waiting on me). >> >> So far, the best I can think of is that I need to go through a copy of >> J source and remove every potential flaw I can find - starting with >> the implementation of jtequ. >> >> But perhaps also there are things I can look for in gdb? >> Unfortunately, my knowledge of intel machine language is woefully >> incomplete, so I do not know specifically what I should be looking >> for. >> >> Thanks, >> >> -- >> Raul >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm >> > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
