Good point by Norbert - I should have referenced a bug - but interested in others experience and I will annotate that bug.
For me, this isn’t a recursion thing, it’s a dnu when restarting a method (not sure if many people do this - but it’s a key Smalltalk feature in my mind - so it should work well). Also my image recovers fine when I shut down the debuggers. Interested in others experience and I guess I should try and use 7 more to see if it’s there too. Tim Sent from my iPhone Sent from my iPhone >> On 8 Jun 2018, at 13:10, Esteban A. Maringolo <emaring...@gmail.com> wrote: >> >> On 08/06/2018 08:30, Tim Mackinnon wrote: >> Hi, I’ve noticed lately when using a reasonably recent Pharo 6.1 setup that >> if I restart a method in the debugger - particularly from a breakpoint or >> correcting a dnu issue the environment frequently locks up. Fearing the >> worst (after a few seconds), if I repeatedly press cmd . (Say 5 times) after >> 10 seconds more it comes back with 30 debugger Windows typically with >> something like Instance of Xxxx dnu: #someMethod (which is legit as I might >> have a now corrupt inst bar). >> >> I understand the error, but why does it lockup and require the cmd . Dance? >> >> I dont recall earlier Pharos doing this (and not other smalltalks). >> >> Should I report this? > > > It was reported years ago [1], there was a bug and an issue, and it was > supposedly fixed, apparently it wasn't. > > In some cases that recursion caused a "detachment" of the image from the > changes, it is, the image starts complaining that it can't find the > changes file, so all methods lose the source and you better discard that > image without saving, because if you do, you'll never be able to > "reattach" it. > > I don't know if it is still around in Pharo 7. > > > Regards, > > [1] https://twitter.com/emaringolo/status/603939752098816000 > > > -- > Esteban A. Maringolo >
