[Pharo-project] Recursion - should there be a limit?
Hello all, I (stupidly) created a runaway recursion that happened to be in a Seaside app that uses LDAPLayer, and that is currently using drives shared over a pre-production vpn from a 64 bit Ubuntu system. Hopefully you won't think less of me for not immediately thinking of infinite recursion as the cause of the problems. It did what is IMHO the worst thing a program can do: it just stopped responding. It makes sense now, and the next time I see the IDE get sluggish and finally lock up, I will probably think of recursion before looking for strange causes. As it was, I simply moved breakpoints around (making liberal use of the End Process button on Ubuntu's system monitor) until I finally put one in front of something that I thought should have worked, and in fact was the culprit. For good or bad, Dolphin would promptly complain of the callstack being too deep, after which the mistake is fairly easy to find. I have never had problems with that limit, but IIRC others have. Would it be simple to add an optional limit on the stack depth? Would you do it, or would it be asking for trouble? Is there a less invasive way to aid in debugging this scenario? Bill
On Aug 22, 2009, at 6:50 PM, Schwab,Wilhelm K wrote:
Hello all,
I (stupidly) created a runaway recursion that happened to be in a Seaside app that uses LDAPLayer, and that is currently using drives shared over a pre-production vpn from a 64 bit Ubuntu system. Hopefully you won't think less of me for not immediately thinking of infinite recursion as the cause of the problems. It did what is IMHO the worst thing a program can do: it just stopped responding. It makes sense now, and the next time I see the IDE get sluggish and finally lock up, I will probably think of recursion before looking for strange causes. As it was, I simply moved breakpoints around (making liberal use of the End Process button on Ubuntu's system monitor) until I finally put one in front of something that I thought should have worked, and in fact was the culprit.
For good or bad, Dolphin would promptly complain of the callstack being too deep, after which the mistake is fairly easy to find. I have never had problems with that limit, but IIRC others have. Would it be simple to add an optional limit on the stack depth? Would you do it, or would it be asking for trouble? Is there a less invasive way to aid in debugging this scenario?
this would be nice because I found myself often impossible to bring a debugger or getting a screen full of wanring windows and I have to kill the image. Improving the debug possibility would be importatn but I have no idea how to address it.
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Would it be simple to add an optional limit on the stack depth?
Yes, because the stack is a linked list of objects. Counting them is expensive.
Would you do it, or would it be asking for trouble? Â Is there a less invasive way to aid in debugging this scenario?
CPUWatcher does something like this, but it also eats valuable CPU cycles. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Sun, Aug 23, 2009 at 4:50 AM, Schwab,Wilhelm K <bschwab@anest.ufl.edu>wrote:
Hello all,
I (stupidly) created a runaway recursion that happened to be in a Seaside app that uses LDAPLayer, and that is currently using drives shared over a pre-production vpn from a 64 bit Ubuntu system. Hopefully you won't think less of me for not immediately thinking of infinite recursion as the cause of the problems. It did what is IMHO the worst thing a program can do: it just stopped responding. It makes sense now, and the next time I see the IDE get sluggish and finally lock up, I will probably think of recursion before looking for strange causes. As it was, I simply moved breakpoints around (making liberal use of the End Process button on Ubuntu's system monitor) until I finally put one in front of something that I thought should have worked, and in fact was the culprit.
For good or bad, Dolphin would promptly complain of the callstack being too deep, after which the mistake is fairly easy to find. I have never had problems with that limit, but IIRC others have. Would it be simple to add an optional limit on the stack depth? Would you do it, or would it be asking for trouble? Is there a less invasive way to aid in debugging this scenario?
For interest's sake, I'm eventually going to be implementing a solution to this called "Dominions". No promises though; I write code slowly but constantly, so it will get written but maybe not this year: http://gulik.pbworks.com/Dominions Briefly, a dominion is used for resource management. You run your code in a "dominion", which has memory, CPU, network and disk usage limits put on it. Different parts of Squeak (well, SecureSqueak) would need to be modified to support this: the scheduler, object creation (and GC?), network, file usage. Yea, it might be slow, but I need resource control more than I need speed. If you ran your code in a dominion and it ignited a fork bomb, only that dominion would be affected. It would run out of memory, stall and alert that dominion's manager... or something. The rest of the image would continue fine, including the UI so that you could debug stuff. That would give Java a good run for its money. Ever had an OutOfMemoryException on a production server before? Gulik. -- http://gulik.pbwiki.com/
participants (4)
-
Lukas Renggli -
Michael van der Gulik -
Schwab,Wilhelm K -
Stéphane Ducasse