Debugging a failing test doesn't include the full stack
I'm trying to debug a failing test case in Pharo 5, but for some reason in certain tests I can't see the full stack, so basically I can't fix nor diagnose the failing test within the debugger because I only get the assert notification. This doesn't happen in Pharo 4, there seems to be a refactoring of the TestCase hierarchy, but I don't know how it affects the exception handling, which in the case of Glorp seems to not be very orthodox. Regards! â Esteban A. Maringolo
I don't know if this is related, but trying to debug another test I got an endless loop of MNU related with Message>>#sendTo: MessageNotUnderstood: BlockClosure>>asSymbol BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol I got this kind of error en Pharo 4 too, but not as soon as trying to debug a failing test. Anybody know why this happen? Regards! Esteban A. Maringolo Log... MessageNotUnderstood: BlockClosure>>asSymbol BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: MessageNotUnderstood: BlockClosure>>asSymbol BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: BlockClosure(Object)>>doesNotUnderstand: #asSymbol Message>>sentTo: ad infinitum... or until Alt+.
On Tue, Nov 24, 2015 at 7:32 AM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
I'm trying to debug a failing test case in Pharo 5, but for some reason in certain tests I can't see the full stack, so basically I can't fix nor diagnose the failing test within the debugger because I only get the assert notification.
This doesn't happen in Pharo 4, there seems to be a refactoring of the TestCase hierarchy, but I don't know how it affects the exception handling, which in the case of Glorp seems to not be very orthodox.
Regards! â
Esteban A. Maringolo
Possible workaround hack is to remove some of the conditions from #on:do: so you get a debugger straight away on the original error rather than storing it for later. TestResult>>runCase: aTestCase [ aTestCase announce: TestCaseStarted withResult: self. aTestCase runCase. aTestCase announce: TestCaseEnded withResult: self. self addPass: aTestCase] on: self class failure , self class skip, self class warning, self class error do: [:ex | ex sunitAnnounce: aTestCase toResult: self] cheers -ben
Iâve seen this problem tons of times since Pharo4. But the worst is that I never found a way to reproduce it. To me there is some side effect somewhere. Because it does not happen in a fresh image, but once you have it, you have it all the time.
On 24 nov 2015, at 1:49 p.m., Ben Coman <btc@openinworld.com> wrote:
On Tue, Nov 24, 2015 at 7:32 AM, Esteban A. Maringolo <emaringolo@gmail.com <mailto:emaringolo@gmail.com>> wrote: I'm trying to debug a failing test case in Pharo 5, but for some reason in certain tests I can't see the full stack, so basically I can't fix nor diagnose the failing test within the debugger because I only get the assert notification.
This doesn't happen in Pharo 4, there seems to be a refactoring of the TestCase hierarchy, but I don't know how it affects the exception handling, which in the case of Glorp seems to not be very orthodox.
Regards! â
Esteban A. Maringolo
Possible workaround hack is to remove some of the conditions from #on:do: so you get a debugger straight away on the original error rather than storing it for later.
TestResult>>runCase: aTestCase [ aTestCase announce: TestCaseStarted withResult: self. aTestCase runCase. aTestCase announce: TestCaseEnded withResult: self. self addPass: aTestCase] on: self class failure , self class skip, self class warning, self class error do: [:ex | ex sunitAnnounce: aTestCase toResult: self]
cheers -ben
2015-11-25 6:32 GMT-03:00 Guillermo Polito <guillermopolito@gmail.com>:
Iâve seen this problem tons of times since Pharo4. But the worst is that I never found a way to reproduce it.
To me there is some side effect somewhere. Because it does not happen in a fresh image, but once you have it, you have it all the time.
I thought it had to do with how GLORP handles the exceptions and/or block unwinding. But it doesn't seem so. There is a bug report for this: https://pharo.fogbugz.com/f/cases/16877/another-endless-debugger-loop Esteban A. Maringolo
I debugged and found the reason of the error. https://pharo.fogbugz.com/f/cases/16877/another-endless-debugger-loop <https://pharo.fogbugz.com/f/cases/16877/another-endless-debugger-loop> The cause, in two words, is that the debugger is not aware of process suspension and the debugger depends on it. So having a debugger that tries to open a debugger creates an endless loop that should be stopped with process suspension in the normal case.
On 25 nov 2015, at 9:32 p.m., Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2015-11-25 6:32 GMT-03:00 Guillermo Polito <guillermopolito@gmail.com>:
Iâve seen this problem tons of times since Pharo4. But the worst is that I never found a way to reproduce it.
To me there is some side effect somewhere. Because it does not happen in a fresh image, but once you have it, you have it all the time.
I thought it had to do with how GLORP handles the exceptions and/or block unwinding. But it doesn't seem so.
There is a bug report for this: https://pharo.fogbugz.com/f/cases/16877/another-endless-debugger-loop
Esteban A. Maringolo
Thank you Guille! Now... how do we fix it? It affects Pharo 4 too. Regards! Esteban A. Maringolo 2015-11-27 11:01 GMT-03:00 Guillermo Polito <guillermopolito@gmail.com>:
I debugged and found the reason of the error.
https://pharo.fogbugz.com/f/cases/16877/another-endless-debugger-loop
The cause, in two words, is that the debugger is not aware of process suspension and the debugger depends on it. So having a debugger that tries to open a debugger creates an endless loop that should be stopped with process suspension in the normal case.
On 25 nov 2015, at 9:32 p.m., Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2015-11-25 6:32 GMT-03:00 Guillermo Polito <guillermopolito@gmail.com>:
Iâve seen this problem tons of times since Pharo4. But the worst is that I never found a way to reproduce it.
To me there is some side effect somewhere. Because it does not happen in a fresh image, but once you have it, you have it all the time.
I thought it had to do with how GLORP handles the exceptions and/or block unwinding. But it doesn't seem so.
There is a bug report for this: https://pharo.fogbugz.com/f/cases/16877/another-endless-debugger-loop
Esteban A. Maringolo
participants (3)
-
Ben Coman -
Esteban A. Maringolo -
Guillermo Polito