recursion (by mistake) causes system lockup in 2014.12.30.nightly

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

recursion (by mistake) causes system lockup in 2014.12.30.nightly

jbeale
Using Debian 7.7 x64, OpenSCAD 2014.12.30.nightly (git bebe084)

I made a simple typo which caused a module to reference itself, instead of another module. There was a long string of "Error - recursion detected in [x]" messages in the console pane, followed by a lot of disk activity (swap space use?) and at that point the system was essentially locked up and I could not close or quit the program; I had to reboot to escape.   It was my fault for the unwanted recursion, but ideally I would not to have to reboot to recover.  I've never tried to use recursion intentionally. Maybe there could be a flag to turn the recursion feature off? Or is there already?
Reply | Threaded
Open this post in threaded view
|

Re: recursion (by mistake) causes system lockup in 2014.12.30.nightly

MichaelAtOz
Administrator
I've had similar on Windows, I set my swap space to a fixed amount (2GB), thus when it is full OpenSCAD crashes, rather than the system hanging. Not sure if that is possible on Linux.

Yes it should handle it properly, there have been some changes in this area recently.
Admin - email* me if you need anything, or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.
Reply | Threaded
Open this post in threaded view
|

Re: recursion (by mistake) causes system lockup in 2014.12.30.nightly

kintel
Administrator
In reply to this post by jbeale
On Dec 31, 2014, at 03:24 AM, jbeale <[hidden email]> wrote:

> There was a long string of "Error - recursion detected in
> [x]" messages in the console pane, followed by a lot of disk activity (swap
> space use?) and at that point the system was essentially locked up

This shouldn’t have been fixed. Could you provide an example .scad file so we can reproduce it and look into it?

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: recursion (by mistake) causes system lockup in 2014.12.30.nightly

Chow Loong Jin
In reply to this post by jbeale
On Wed, Dec 31, 2014 at 01:24:47AM -0700, jbeale wrote:

> Using Debian 7.7 x64, OpenSCAD 2014.12.30.nightly (git bebe084)
>
> I made a simple typo which caused a module to reference itself, instead of
> another module. There was a long string of "Error - recursion detected in
> [x]" messages in the console pane, followed by a lot of disk activity (swap
> space use?) and at that point the system was essentially locked up and I
> could not close or quit the program; I had to reboot to escape.   It was my
> fault for the unwanted recursion, but ideally I would not to have to reboot
> to recover.  I've never tried to use recursion intentionally. Maybe there
> could be a flag to turn the recursion feature off? Or is there already?
You don't have to reboot to recover. If your disk i/o is slow, you just have to
wait. It might be a long wait, though. :D

On the bright side, there are SysRq keys that can save you the wait:

Alt+SysRq+f: Trigger the OOM killer (Think Russian Roulette with a bias on
high-memory-consumption processes until OpenSCAD dies)

Alt+SysRq+k: Kill the entire TTY (Xorg and everything that depends on it,
including OpenSCAD).

--
Kind regards,
Loong Jin

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: recursion (by mistake) causes system lockup in 2014.12.30.nightly

laird
This post has NOT been accepted by the mailing list yet.
In reply to this post by MichaelAtOz
I'd point out that even when intentionally recursing, it's easy to accidentally infinitely recurse. So rather than turning recursion on/off, I'd like to see terminating accidental infinite recursions easier.

There is a cancel button in the GUI (the x in the bottom right corner, when rendering) but the GUI doesn't appear very responsive to it - canceling often takes a very long time to take effect. Is there any way to make the cancel higher priority, or checked for more often, so that you can interrupt things like infinite recursion?

It'd also be nice to have the GUI respond to a key stroke (e.g. control-C or ESC) to cancel a rendering. At least for me - after all these years, my brain is wired to hit keys to cancel operations ASAP. As far as I can tell, OpenSCAD ignores both keystrokes in the GUI.

One other idea - perhaps we could set the maximum recursion level in code, as a "magic variable" such as $max_recursion? That way, if you're writing something that you expect to recurse a given number of levels, exceeding that limit would cause the program to terminate with an error message. By default there should be no fixed limit, of course. But for example, when I recursively generate trees or snowflakes, I know that I'm going to recurse a fixed number of times, and if I exceed that it's a bug. It's be nice to terminate automatically in those cases, since infinite recursion often causes the system to hang, or the GUI to hang, wastes a lot of time rebooting/restarting OpenSCAD, reloading the saved code, etc.

I will say that in these cases, the automatic backups saved by OpenSCAD are life savers. I don't know whose idea that was, but THANKS!