So I opened this case 19108 <https://pharo.fogbugz.com/f/cases/19108/Logging-error-stack-should-not-hang-image-and-prevent-opening-debugger> and submitted slice which restricts logging time to 100 milliseconds. (it should be enough, look at issue explanation).
But also there is some problem with GTDebugger which talk with full stack items instead of visible ones. It slowdown opening on big stack (which is usual for recursion cases). To see problem just open in browser Context>>sender and put counter on sender variable (from suggestion menu). Also disable stack logging by "DebugSession logDebuggerStackToFile: false". Now execute "1 recursionTest" from workspace and after 3 seconds press cmd+.. You will see 11610 calls of "context sender". Interesting that with SpecDebugger it is just 42 calls. 2016-08-16 11:30 GMT+02:00 Max Leske <maxle...@gmail.com>: > > On 16 Aug 2016, at 10:11, Denis Kudriashov <dionisi...@gmail.com> wrote: > > > 2016-08-14 10:19 GMT+02:00 Sven Van Caekenberghe <s...@stfx.eu>: > >> But the slowness comes from printing a too large stack, no ? >> Why not just limit the size of the stack being printed ? >> > > Maybe it is better to limit time which could be spend on log writing. > Sometime I guess writing to log itself raises errors and recursions which > could be another reason for non working cmd+.. > We could limit it for 1 second. And if it is not enough then append extra > ~20 contexts from root which will show reason for possible recursion (also > limited in time). What you think? > > > That sounds like too much magic to me... > >
