Smalltalk › Pharo › Pharo Smalltalk Developers

Debugging a failing test doesn't include the full stack

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Esteban A. Maringolo

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

Re: Debugging a failing test doesn't include the full stack

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+.

Ben Coman

Re: Debugging a failing test doesn't include the full stack

In reply to this post by Esteban A. Maringolo

On Tue, Nov 24, 2015 at 7:32 AM, Esteban A. Maringolo <[hidden email]> 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

Guillermo Polito

Re: Debugging a failing test doesn't include the full stack

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 <[hidden email]> wrote:

On Tue, Nov 24, 2015 at 7:32 AM, Esteban A. Maringolo <[hidden email]> 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

Esteban A. Maringolo

Re: Debugging a failing test doesn't include the full stack

2015-11-25 6:32 GMT-03:00 Guillermo Polito <[hidden email]>:
> 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

Guillermo Polito

Re: Debugging a failing test doesn't include the full stack

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 <[hidden email]> wrote:

2015-11-25 6:32 GMT-03:00 Guillermo Polito <[hidden email]>:
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

Esteban A. Maringolo

Re: Debugging a failing test doesn't include the full stack

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 <[hidden email]>:

> 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 <[hidden email]>
> wrote:
>
> 2015-11-25 6:32 GMT-03:00 Guillermo Polito <[hidden email]>:
>
> 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
>
>