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 |
Hi. 2016-09-18 14:22 GMT+02:00 Hilaire <[hidden email]>:
Try to disable logging errors by
It could make "alt+." work |
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 |
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 |
The log file I forgot to join to my previous post.
Hilaire -- Dr. Geo http://drgeo.eu PharoDebug.log.zip (14K) Download Attachment |
In reply to this post by HilaireFernandes
2016-09-18 15:26 GMT+02:00 Hilaire <[hidden email]>:
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. |
Hi denis Could you propose a way to speed up the stack? Write less :) Stef Le 18/9/16 à 16:52, Denis Kudriashov a
écrit :
|
2016-09-18 17:31 GMT+02:00 stepharo <[hidden email]>:
|
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 --------
|
Also in latest version we integrate this fix: 16877 2016-09-19 10:21 GMT+02:00 Guille Polito <[hidden email]>:
|
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 |
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. |
2016-09-21 12:11 GMT+02:00 Guille Polito <[hidden email]>:
But be careful. It could lead to multiple UI processes which will cause strange things on screen. |
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 |
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 > > |
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 opened issue 19848 2017-03-16 16:36 GMT+01:00 Denis Kudriashov <[hidden email]>:
|
And it works in Squeak 2017-03-16 16:56 GMT+01:00 Denis Kudriashov <[hidden email]>:
|
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ó:
|
2017-03-16 18:07 GMT+01:00 Esteban A. Maringolo <[hidden email]>:
No. Problem is in Context methods: #stepToHome: and #runUntilErrorOrReturnFrom:. They called from DebugSession #stepThrough: and #stepOver: |
Free forum by Nabble | Edit this page |