doesNotUnderstand: infinit loop

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

doesNotUnderstand: infinit loop

HilaireFernandes
Hi,


My Pharo4.0 image is in a situation where each MNU exception throw from
a DNU result in infinite loop, locking the image, even not breakable
with alt+[.].

From the doesNotUnderstand: message,
the "exception reachedDefaultHandler" always returns true, and it
results in the execution of the true block, sending again the original
message to the original object, repeating a DNU and so on.

Any idea how to fix that?

Thanks

Hilaire



doesNotUnderstand: aMessage
         "Handle the fact that there was an attempt to send the given message
to the receiver but the receiver does not understand this message
(typically sent from the machine when a message is sent to the receiver
and no method is defined for that selector)."
        "Testing: (3 activeProcess)"
               
        | exception resumeValue |
        (exception := MessageNotUnderstood new)
                message: aMessage;
                receiver: self.
        resumeValue := exception signal.
        ^exception reachedDefaultHandler
                ifTrue: [aMessage sentTo: self]
                ifFalse: [resumeValue]


--
Dr. Geo
http://drgeo.eu


Reply | Threaded
Open this post in threaded view
|

Re: doesNotUnderstand: infinit loop

Denis Kudriashov
Hi.

2016-09-18 14:22 GMT+02:00 Hilaire <[hidden email]>:
Hi,


My Pharo4.0 image is in a situation where each MNU exception throw from
a DNU result in infinite loop, locking the image, even not breakable
with alt+[.].

Try to disable logging errors by 
DebugSession logDebuggerStackToFile: false
It could make "alt+." work
Reply | Threaded
Open this post in threaded view
|

Re: doesNotUnderstand: infinit loop

HilaireFernandes
In reply to this post by HilaireFernandes
I forget to notice the debugger does not show up.
I tried to trace it, but I don't have enough background knowledge on MNU
and debugger to understand what is going on.

Hilaire

--
Dr. Geo
http://drgeo.eu


Reply | Threaded
Open this post in threaded view
|

Re: doesNotUnderstand: infinit loop

HilaireFernandes
In reply to this post by Denis Kudriashov
I guess you meant SpecDebugger.
I can alt+., but at the end I have to kill Pharo from the system.

Enclosed the .log file.
I don't know why there is lot of noise in the debug log, it is hard to
understand what is going on.

Thanks

Hilaire


Le 18/09/2016 à 15:06, Denis Kudriashov a écrit :
>     DebugSession logDebuggerStackToFile: false
>
> It could make "alt+." work

--
Dr. Geo
http://drgeo.eu


Reply | Threaded
Open this post in threaded view
|

Re: doesNotUnderstand: infinit loop

HilaireFernandes
The log file I forgot to join to my previous post.

Hilaire
--
Dr. Geo
http://drgeo.eu

PharoDebug.log.zip (14K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: doesNotUnderstand: infinit loop

Denis Kudriashov
In reply to this post by HilaireFernandes

2016-09-18 15:26 GMT+02:00 Hilaire <[hidden email]>:
I guess you meant SpecDebugger.
I can alt+., but at the end I have to kill Pharo from the system.

Enclosed the .log file.
I don't know why there is lot of noise in the debug log, it is hard to
understand what is going on.

Hilaire. In lastest Pharo we investigate why process interruption with cmd+. is not working sometime. 
Main reason was that system write stack to file before opening debugger. And it could be really slow which will delay debugger for the long time.
That's why I suggest disable logging. In my cases it makes cmd+. works well.

Reply | Threaded
Open this post in threaded view
|

Re: doesNotUnderstand: infinit loop

stepharo

Hi denis

Could you propose a way to speed up the stack? Write less :)

Because interrupting an endless or other would be good.

Stef

Le 18/9/16 à 16:52, Denis Kudriashov a écrit :

2016-09-18 15:26 GMT+02:00 Hilaire <[hidden email]>:
I guess you meant SpecDebugger.
I can alt+., but at the end I have to kill Pharo from the system.

Enclosed the .log file.
I don't know why there is lot of noise in the debug log, it is hard to
understand what is going on.

Hilaire. In lastest Pharo we investigate why process interruption with cmd+. is not working sometime. 
Main reason was that system write stack to file before opening debugger. And it could be really slow which will delay debugger for the long time.
That's why I suggest disable logging. In my cases it makes cmd+. works well.


Reply | Threaded
Open this post in threaded view
|

Re: doesNotUnderstand: infinit loop

Denis Kudriashov
Hi.

I propose this 19108.


2016-09-18 17:31 GMT+02:00 stepharo <[hidden email]>:

Hi denis

Could you propose a way to speed up the stack? Write less :)

Because interrupting an endless or other would be good.

Stef

Le 18/9/16 à 16:52, Denis Kudriashov a écrit :

2016-09-18 15:26 GMT+02:00 Hilaire <[hidden email]>:
I guess you meant SpecDebugger.
I can alt+., but at the end I have to kill Pharo from the system.

Enclosed the .log file.
I don't know why there is lot of noise in the debug log, it is hard to
understand what is going on.

Hilaire. In lastest Pharo we investigate why process interruption with cmd+. is not working sometime. 
Main reason was that system write stack to file before opening debugger. And it could be really slow which will delay debugger for the long time.
That's why I suggest disable logging. In my cases it makes cmd+. works well.



Reply | Threaded
Open this post in threaded view
|

Re: doesNotUnderstand: infinit loop

Guillermo Polito
In reply to this post by stepharo
Hi,

I was suffering from this infinite loop since a long time. Last week I thought I was able to reproduce it but as soon as I tried to fix it I could not reproduce it anymore... So I wasn't able to tell if I fixed it or not.

The only thing I can say is that this is difficult to interrupt not because of the logging (which is a problem for large stacks) but because this is caused by a short lived process that spawns new processes. Thus, lots of processes are created and the interruptions could interrupt any of them...

Hillaire, if you have an image with the problem, can you forward it to me? I'm looking forward to kill this bug with my axe.

Guille

-------- Original Message --------

Hi denis

Could you propose a way to speed up the stack? Write less :)

Because interrupting an endless or other would be good.

Stef

Le 18/9/16 à 16:52, Denis Kudriashov a écrit :

2016-09-18 15:26 GMT+02:00 Hilaire <[hidden email]>:
I guess you meant SpecDebugger.
I can alt+., but at the end I have to kill Pharo from the system.

Enclosed the .log file.
I don't know why there is lot of noise in the debug log, it is hard to
understand what is going on.

Hilaire. In lastest Pharo we investigate why process interruption with cmd+. is not working sometime. 
Main reason was that system write stack to file before opening debugger. And it could be really slow which will delay debugger for the long time.
That's why I suggest disable logging. In my cases it makes cmd+. works well.



Reply | Threaded
Open this post in threaded view
|

Re: doesNotUnderstand: infinit loop

Denis Kudriashov
Also in latest version we integrate this fix: 16877

2016-09-19 10:21 GMT+02:00 Guille Polito <[hidden email]>:
Hi,

I was suffering from this infinite loop since a long time. Last week I thought I was able to reproduce it but as soon as I tried to fix it I could not reproduce it anymore... So I wasn't able to tell if I fixed it or not.

The only thing I can say is that this is difficult to interrupt not because of the logging (which is a problem for large stacks) but because this is caused by a short lived process that spawns new processes. Thus, lots of processes are created and the interruptions could interrupt any of them...

Hillaire, if you have an image with the problem, can you forward it to me? I'm looking forward to kill this bug with my axe.

Guille


-------- Original Message --------

Hi denis

Could you propose a way to speed up the stack? Write less :)

Because interrupting an endless or other would be good.

Stef

Le 18/9/16 à 16:52, Denis Kudriashov a écrit :

2016-09-18 15:26 GMT+02:00 Hilaire <[hidden email]>:
I guess you meant SpecDebugger.
I can alt+., but at the end I have to kill Pharo from the system.

Enclosed the .log file.
I don't know why there is lot of noise in the debug log, it is hard to
understand what is going on.

Hilaire. In lastest Pharo we investigate why process interruption with cmd+. is not working sometime. 
Main reason was that system write stack to file before opening debugger. And it could be really slow which will delay debugger for the long time.
That's why I suggest disable logging. In my cases it makes cmd+. works well.




Reply | Threaded
Open this post in threaded view
|

Re: doesNotUnderstand: infinit loop

HilaireFernandes
In reply to this post by Guillermo Polito
Guille,

Can you send me your email at hilaire [at] drgeo.eu, I can't have it
through the Gmane news forum.

Hilaire

Le 19/09/2016 à 10:21, Guille Polito a écrit :
> Hillaire, if you have an image with the problem, can you forward it to
> me? I'm looking forward to kill this bug with my axe.

--
Dr. Geo
http://drgeo.eu


Reply | Threaded
Open this post in threaded view
|

Re: doesNotUnderstand: infinit loop

Guillermo Polito
Hi Hilaire, all,

I started digging this morning on this issue, and I see why we can have
such problems.

Apparently, there is some strange case that produces a bug in UIManager.
To explain it with code, the UIManager should satisfy allways the
following invariant.

"If executed from a workspace/playground. i.e., the UI process itself:"
UIManager default uiProcess == Processor activeProcess. => true

Somehow, in the image you provided me, it is not the case.

I'm still taking a look at what would cause this. And I also think we
still have this bug in pharo 6 (and thus pharo 5) because I found it
lately very often.

In the meantime, if you find that your image is causing you these
problems, you can workaround it by executing:

UIManager default spawnNewProcess.

Once you do that, the ui process should come back to a correct state and
the debugger should behave as expected.

Guille

-------- Original Message --------

> Guille,
>
> Can you send me your email at hilaire [at] drgeo.eu, I can't have it
> through the Gmane news forum.
>
> Hilaire
>
> Le 19/09/2016 à 10:21, Guille Polito a écrit :
>> Hillaire, if you have an image with the problem, can you forward it to
>> me? I'm looking forward to kill this bug with my axe.


Reply | Threaded
Open this post in threaded view
|

Re: doesNotUnderstand: infinit loop

Denis Kudriashov

2016-09-21 12:11 GMT+02:00 Guille Polito <[hidden email]>:

I'm still taking a look at what would cause this. And I also think we still have this bug in pharo 6 (and thus pharo 5) because I found it lately very often.

In the meantime, if you find that your image is causing you these problems, you can workaround it by executing:

UIManager default spawnNewProcess.

But be careful. It could lead to multiple UI processes which will cause strange things on screen.
Reply | Threaded
Open this post in threaded view
|

Re: doesNotUnderstand: infinit loop

HilaireFernandes
In reply to this post by Guillermo Polito
Hi Guille,

I was wondering if I could have kill manually this process, but the
process browser does not let you do that mistake.

Thanks for the tip.

Hilaire

Le 21/09/2016 à 12:11, Guille Polito a écrit :

> Hi Hilaire, all,
>
> I started digging this morning on this issue, and I see why we can have
> such problems.
>
> Apparently, there is some strange case that produces a bug in UIManager.
> To explain it with code, the UIManager should satisfy allways the
> following invariant.
>
> "If executed from a workspace/playground. i.e., the UI process itself:"
> UIManager default uiProcess == Processor activeProcess. => true
>
> Somehow, in the image you provided me, it is not the case.
>
> I'm still taking a look at what would cause this. And I also think we
> still have this bug in pharo 6 (and thus pharo 5) because I found it
> lately very often.
>
> In the meantime, if you find that your image is causing you these
> problems, you can workaround it by executing:
>
> UIManager default spawnNewProcess.
>
> Once you do that, the ui process should come back to a correct state and
> the debugger should behave as expected.
>
> Guille

--
Dr. Geo
http://drgeo.eu


Reply | Threaded
Open this post in threaded view
|

Re: doesNotUnderstand: infinit loop

Esteban A. Maringolo
Was this fixed?

I'm debugging unit tests and I'm getting an infinte loop everytime a
MNU is triggered.

MessageNotUnderstood: receiver of "new" is nil
UndefinedObject(Object)>>doesNotUnderstand: #new
Message>>sentTo:
UndefinedObject(Object)>>doesNotUnderstand: #new
Message>>sentTo:

VM: Unix built on May  4 2016 11:54:41 Compiler: 4.6.3
CoInterpreter VMMaker.oscog-eem.1855 uuid:
d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May  4 2016
StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid:
d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May  4 2016
https://github.com/pharo-project/pharo-vm.git Commit:
b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22
+0200 Jenkins build #589

Image: 6521

Best regards,

Esteban A. Maringolo


2016-09-21 15:01 GMT-03:00 Hilaire <[hidden email]>:

> Hi Guille,
>
> I was wondering if I could have kill manually this process, but the
> process browser does not let you do that mistake.
>
> Thanks for the tip.
>
> Hilaire
>
> Le 21/09/2016 à 12:11, Guille Polito a écrit :
>> Hi Hilaire, all,
>>
>> I started digging this morning on this issue, and I see why we can have
>> such problems.
>>
>> Apparently, there is some strange case that produces a bug in UIManager.
>> To explain it with code, the UIManager should satisfy allways the
>> following invariant.
>>
>> "If executed from a workspace/playground. i.e., the UI process itself:"
>> UIManager default uiProcess == Processor activeProcess. => true
>>
>> Somehow, in the image you provided me, it is not the case.
>>
>> I'm still taking a look at what would cause this. And I also think we
>> still have this bug in pharo 6 (and thus pharo 5) because I found it
>> lately very often.
>>
>> In the meantime, if you find that your image is causing you these
>> problems, you can workaround it by executing:
>>
>> UIManager default spawnNewProcess.
>>
>> Once you do that, the ui process should come back to a correct state and
>> the debugger should behave as expected.
>>
>> Guille
>
> --
> Dr. Geo
> http://drgeo.eu
>
>

Reply | Threaded
Open this post in threaded view
|

Re: doesNotUnderstand: infinit loop

Denis Kudriashov
That is sad. It works from workspace but not during debugging tests.

2017-03-16 15:11 GMT+01:00 Esteban A. Maringolo <[hidden email]>:
Was this fixed?

I'm debugging unit tests and I'm getting an infinte loop everytime a
MNU is triggered.

MessageNotUnderstood: receiver of "new" is nil
UndefinedObject(Object)>>doesNotUnderstand: #new
Message>>sentTo:
UndefinedObject(Object)>>doesNotUnderstand: #new
Message>>sentTo:

VM: Unix built on May  4 2016 11:54:41 Compiler: 4.6.3
CoInterpreter VMMaker.oscog-eem.1855 uuid:
d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May  4 2016
StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid:
d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May  4 2016
https://github.com/pharo-project/pharo-vm.git Commit:
b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22
+0200 Jenkins build #589

Image: 6521

Best regards,

Esteban A. Maringolo


2016-09-21 15:01 GMT-03:00 Hilaire <[hidden email]>:
> Hi Guille,
>
> I was wondering if I could have kill manually this process, but the
> process browser does not let you do that mistake.
>
> Thanks for the tip.
>
> Hilaire
>
> Le 21/09/2016 à 12:11, Guille Polito a écrit :
>> Hi Hilaire, all,
>>
>> I started digging this morning on this issue, and I see why we can have
>> such problems.
>>
>> Apparently, there is some strange case that produces a bug in UIManager.
>> To explain it with code, the UIManager should satisfy allways the
>> following invariant.
>>
>> "If executed from a workspace/playground. i.e., the UI process itself:"
>> UIManager default uiProcess == Processor activeProcess. => true
>>
>> Somehow, in the image you provided me, it is not the case.
>>
>> I'm still taking a look at what would cause this. And I also think we
>> still have this bug in pharo 6 (and thus pharo 5) because I found it
>> lately very often.
>>
>> In the meantime, if you find that your image is causing you these
>> problems, you can workaround it by executing:
>>
>> UIManager default spawnNewProcess.
>>
>> Once you do that, the ui process should come back to a correct state and
>> the debugger should behave as expected.
>>
>> Guille
>
> --
> Dr. Geo
> http://drgeo.eu
>
>


Reply | Threaded
Open this post in threaded view
|

Re: doesNotUnderstand: infinit loop

Denis Kudriashov
I opened issue 19848

2017-03-16 16:36 GMT+01:00 Denis Kudriashov <[hidden email]>:
That is sad. It works from workspace but not during debugging tests.

2017-03-16 15:11 GMT+01:00 Esteban A. Maringolo <[hidden email]>:
Was this fixed?

I'm debugging unit tests and I'm getting an infinte loop everytime a
MNU is triggered.

MessageNotUnderstood: receiver of "new" is nil
UndefinedObject(Object)>>doesNotUnderstand: #new
Message>>sentTo:
UndefinedObject(Object)>>doesNotUnderstand: #new
Message>>sentTo:

VM: Unix built on May  4 2016 11:54:41 Compiler: 4.6.3
CoInterpreter VMMaker.oscog-eem.1855 uuid:
d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May  4 2016
StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid:
d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May  4 2016
https://github.com/pharo-project/pharo-vm.git Commit:
b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22
+0200 Jenkins build #589

Image: 6521

Best regards,

Esteban A. Maringolo


2016-09-21 15:01 GMT-03:00 Hilaire <[hidden email]>:
> Hi Guille,
>
> I was wondering if I could have kill manually this process, but the
> process browser does not let you do that mistake.
>
> Thanks for the tip.
>
> Hilaire
>
> Le 21/09/2016 à 12:11, Guille Polito a écrit :
>> Hi Hilaire, all,
>>
>> I started digging this morning on this issue, and I see why we can have
>> such problems.
>>
>> Apparently, there is some strange case that produces a bug in UIManager.
>> To explain it with code, the UIManager should satisfy allways the
>> following invariant.
>>
>> "If executed from a workspace/playground. i.e., the UI process itself:"
>> UIManager default uiProcess == Processor activeProcess. => true
>>
>> Somehow, in the image you provided me, it is not the case.
>>
>> I'm still taking a look at what would cause this. And I also think we
>> still have this bug in pharo 6 (and thus pharo 5) because I found it
>> lately very often.
>>
>> In the meantime, if you find that your image is causing you these
>> problems, you can workaround it by executing:
>>
>> UIManager default spawnNewProcess.
>>
>> Once you do that, the ui process should come back to a correct state and
>> the debugger should behave as expected.
>>
>> Guille
>
> --
> Dr. Geo
> http://drgeo.eu
>
>



Reply | Threaded
Open this post in threaded view
|

Re: doesNotUnderstand: infinit loop

Denis Kudriashov
And it works in Squeak

2017-03-16 16:56 GMT+01:00 Denis Kudriashov <[hidden email]>:
I opened issue 19848

2017-03-16 16:36 GMT+01:00 Denis Kudriashov <[hidden email]>:
That is sad. It works from workspace but not during debugging tests.

2017-03-16 15:11 GMT+01:00 Esteban A. Maringolo <[hidden email]>:
Was this fixed?

I'm debugging unit tests and I'm getting an infinte loop everytime a
MNU is triggered.

MessageNotUnderstood: receiver of "new" is nil
UndefinedObject(Object)>>doesNotUnderstand: #new
Message>>sentTo:
UndefinedObject(Object)>>doesNotUnderstand: #new
Message>>sentTo:

VM: Unix built on May  4 2016 11:54:41 Compiler: 4.6.3
CoInterpreter VMMaker.oscog-eem.1855 uuid:
d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May  4 2016
StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid:
d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May  4 2016
https://github.com/pharo-project/pharo-vm.git Commit:
b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22
+0200 Jenkins build #589

Image: 6521

Best regards,

Esteban A. Maringolo


2016-09-21 15:01 GMT-03:00 Hilaire <[hidden email]>:
> Hi Guille,
>
> I was wondering if I could have kill manually this process, but the
> process browser does not let you do that mistake.
>
> Thanks for the tip.
>
> Hilaire
>
> Le 21/09/2016 à 12:11, Guille Polito a écrit :
>> Hi Hilaire, all,
>>
>> I started digging this morning on this issue, and I see why we can have
>> such problems.
>>
>> Apparently, there is some strange case that produces a bug in UIManager.
>> To explain it with code, the UIManager should satisfy allways the
>> following invariant.
>>
>> "If executed from a workspace/playground. i.e., the UI process itself:"
>> UIManager default uiProcess == Processor activeProcess. => true
>>
>> Somehow, in the image you provided me, it is not the case.
>>
>> I'm still taking a look at what would cause this. And I also think we
>> still have this bug in pharo 6 (and thus pharo 5) because I found it
>> lately very often.
>>
>> In the meantime, if you find that your image is causing you these
>> problems, you can workaround it by executing:
>>
>> UIManager default spawnNewProcess.
>>
>> Once you do that, the ui process should come back to a correct state and
>> the debugger should behave as expected.
>>
>> Guille
>
> --
> Dr. Geo
> http://drgeo.eu
>
>




Reply | Threaded
Open this post in threaded view
|

Re: doesNotUnderstand: infinit loop

Esteban A. Maringolo
In reply to this post by Denis Kudriashov
I got used to save the image before debugging a single test and/or recover lost changes. But this is certainly hard if you want to do TDD :)

Is this related with the debugger UI (GT) or with the underlying frameworks?

Regards,

--
Esteban


El mar. 16, 2017 12:37 PM, "Denis Kudriashov" <[hidden email]> escribió:
That is sad. It works from workspace but not during debugging tests.

2017-03-16 15:11 GMT+01:00 Esteban A. Maringolo <[hidden email]>:
Was this fixed?

I'm debugging unit tests and I'm getting an infinte loop everytime a
MNU is triggered.
Reply | Threaded
Open this post in threaded view
|

Re: doesNotUnderstand: infinit loop

Denis Kudriashov

2017-03-16 18:07 GMT+01:00 Esteban A. Maringolo <[hidden email]>:
I got used to save the image before debugging a single test and/or recover lost changes. But this is certainly hard if you want to do TDD :)

Is this related with the debugger UI (GT) or with the underlying frameworks?

No. Problem is in Context methods: #stepToHome: and #runUntilErrorOrReturnFrom:. They called from DebugSession #stepThrough: and #stepOver: 
12