1. I will add some more logging diagnostics. Thanks. This will hopefully help me find the line where it fails.
2. It has been failing well after midnight. Here is the last logged timestamp: 2014 8 19 6 33 49.8605 That's UTC and the machine is in Virginia. I expect some variation between logged timestamps, but at this point it has been almost 8 hours, which is absurd. Here's the time stamps leading up to that one: 2014 8 19 6 25 7.10664 2014 8 19 6 27 10.9633 2014 8 19 6 28 4.43705 2014 8 19 6 28 4.43733 2014 8 19 6 28 19.1738 2014 8 19 6 30 49.565 2014 8 19 6 32 45.5204 2014 8 19 6 33 42.4689 2014 8 19 6 33 42.4692 2014 8 19 6 33 49.8605 I am not using locales for this processing. Keep in mind also that the stack trace showed that the code has stalled in the ~. monad and that it is specifically trying to evaluate equality (or I think that that is what the presence of jtnub and jtequ mean, in that stack trace.). I think this means that locales are an unlikely culprit. I like the way you are thinking, but it's way too easy to think "off track" about these kinds of issues. Debugging requires something of a conflicting set of thought processes - you cannot reject anything without evidence but must be extremely skeptical about every possibility as well as extremely tolerant about every possibility and very evidence based about your conclusions. It's... frustrating. I'm going to go for a walk and get something to eat, maybe that will help my thinking. Then I'll give this another shot with logging around my use of the ~. monad. Thanks, -- Raul On Tue, Aug 19, 2014 at 9:50 AM, 'Pascal Jasmin' via Programming <[email protected]> wrote: > Some ideas, sorry in advance if they are unhelpful, > > 1. step 1 would be finding if it stalls deterministically from code. Perhaps > liberally sprinkling console/logfile output can help. > > 2. "almost 24 hours" - are there time comparisons going on? utc time? > something that might fail close to midnight? Look for other branches/tests > that are nearly always true. Perhaps over nearly 24 hours, the size of > something gets very large/overflows... Could you be running out of locale > numbers? ... > > > ----- Original Message ----- > From: Raul Miller <[email protected]> > To: Programming forum <[email protected]> > Cc: > Sent: Tuesday, August 19, 2014 9:39:21 AM > Subject: [Jprogramming] stalled J processes > > 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
