We also have an OutOfMemory exception, we even have tests provoking such a situation (check usage).
However, I believe such tight loops end up in JIT machine code. Checking stack overflow on each stack manipulation is costly. But I totally agree that we should try to catch these situations even if there is a cost. > On 25 Apr 2019, at 14:39, Esteban Maringolo <[email protected]> wrote: > > I just checked in VisualWorks, where I also develop Seaside and also > make these mistakes, and these recursions launch a "Process Monitor > Emergency: No space left" process monitor, with the option of killing > any running Smalltalk process. > > Regards, > > Esteban A. Maringolo > > On Thu, Apr 25, 2019 at 9:30 AM Esteban Maringolo <[email protected]> > wrote: >> >> Hi, >> >> Is there a way to add deep recursion protection to the system? >> >> eg. >> RecursiveObject>>#recurse >> self recurse >> >> So calling `RecursiveObject new recurse` in Dolphin raises an >> exception right away... >> >> Throws the following error with this stack: >> ProcessorScheduler>>stackOverflow: >> [] in ProcessorScheduler>>vmi:list:no:with: >> BlockClosure>>ifCurtailed: >> ProcessorScheduler>>vmi:list:no:with: >> RecursiveObject>>recurse >> RecursiveObject>>recurse >> >> In Pharo it goes forever until it hits the memory limit (3.6GiB), at >> which point doing an Alt+. is useless and you have to kill the VM. >> >> The example is pretty simple, but when doing Seaside rendering, it is >> easy to miss some return, causing the receiver to render recursively, >> turning your image useless. >> >> e.g. >> MyComponent>>renderContentOn: html >> html render: self someSubComponent >> >> MyComponent>>someSubComponent >> "Here I forget returning the subcomponent" >> someSubComponent ifNil: [someSubcomponent := OtherComponent new]. >> >> When you render MyComponent... boom, because >> #MyComponent>>#renderContentOn: will be called recursively. >> >> Regards, >> >> Esteban A. Maringolo >
