Hi Guille,

On Jun 29, 2018, at 7:48 AM, Guillermo Polito <guillermopolito@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