Hi Guille, > On Jun 29, 2018, at 7:48 AM, Guillermo Polito <guillermopol...@gmail.com> > wrote: > > Hi all, > > during today's sprint we have been working with lots of people on the > infinite debugger problem (https://pharo.fogbugz.com/f/cases/22085/). We have > checked the emails sent in the latest month. Then, together with Quentin, > Pablo, Pavel, Yoan we have been discussing and testing hypothesis all day. We > have been also comparing the debuggers code between pharo 3/4 (where the bug > was is present) and pharo 7, but this was not necessarily straight forward as > the code is not the same and there is no easy diff...
This is frustrating. I can’t see the issue cuz I can’t login to fogbugz. Having to login to read an issue is a major flaw. I can see it makes sense for submitting, but fir merely browsing it should be unacceptable. That said... The pragma <primitive: 199> actually sets the primitive number in the method, so it it not merely a pragma; it alters bits in the method that the VM uses to search for handler contexts. So why one would do that for evaluateSignal: makes no sense to me. The primitive should be set only in on:do: or something very similar (for example one could imagine adding on:or:do: instead of using , to construct an ExceptionSet). So I think removing it from evaluateSignal: is definitely the right thing to do. As far as tests for findNextHandlerFrom:, this is tested implicitly by any nested exception test so I expect you have several tests affected. Clément points to a test that fails when not including <primitive: 199> in evaluateSignal: so more investigation is necessary. Difficult to do while bugs are hidden in fogbugz. When are they going to migrate the github where they belong? > > AAAAND, we have found that the problem may come from a wrong pragma marker. > Just removing that pragma gives us back the same behaviour as in Pharo 3/4. > :D > > https://github.com/pharo-project/pharo/pull/1621 > > I know that the exception handling/debugging has been modified several times > in the latest years (some refactorings, hiding contexts...), we unfortunately > don't have tests for it, so I'd like some more pair of eyes on it. Ben, > Martin could you take a look? > > Thanks all for the fish, > Guille
