Hi guys I need your brain cells. When I execute the test testBasic | context process debugger printedString | context := [ 20 factorial ] asContext. process := Process forContext: context priority: Processor userInterruptPriority. debugger := Smalltalk tools debugger new process: process controller: nil context: context. debugger stack expand. self assert: debugger stack selectedIndex = 1. printedString := OpalCompiler isActive ifTrue: [ '[ 20 factorial ] in DebuggerTest>>testBasic'] ifFalse: [ '[...] in DebuggerTest>>testBasic' ]. self assert: debugger stack selectedItem printString = printedString. debugger send. debugger send. self assert: debugger code getText = (Integer>>#factorial) sourceCode. self assert: debugger stack selectedItem printString = 'SmallInteger(Integer)>>factorial'. two times my image (latest get totally unusable). I thought that may be the process should be terminated so I added process terminate But nothing changes. I tried to debug the code but not chance. I tried self halt after [ 20 factorial ] asContext. I tried to execute the beginning in a workspace and not as a test to eliminate problem. But again no chance. So did I miss something obvious? Stef
even using ensure: to make sure that the process is terminated it is not really working. I have the impression that there is a problem and that the tests does not really finishes but this is really difficult to debug.
Hi guys
I need your brain cells.
When I execute the test
testBasic | context process debugger printedString | context := [ 20 factorial ] asContext.
process := Process forContext: context priority: Processor userInterruptPriority.
debugger := Smalltalk tools debugger new process: process controller: nil context: context. debugger stack expand.
self assert: debugger stack selectedIndex = 1. printedString := OpalCompiler isActive ifTrue: [ '[ 20 factorial ] in DebuggerTest>>testBasic'] ifFalse: [ '[...] in DebuggerTest>>testBasic' ]. self assert: debugger stack selectedItem printString = printedString.
debugger send. debugger send. self assert: debugger code getText = (Integer>>#factorial) sourceCode. self assert: debugger stack selectedItem printString = 'SmallInteger(Integer)>>factorial'.
two times my image (latest get totally unusable). I thought that may be the process should be terminated so I added
process terminate
But nothing changes. I tried to debug the code but not chance. I tried self halt after [ 20 factorial ] asContext.
I tried to execute the beginning in a workspace and not as a test to eliminate problem. But again no chance.
So did I miss something obvious?
Stef
When I use | context process | context := [ 20 factorial ] asContext. process := Process forContext: context priority: Processor userInterruptPriority. [ debugger := Smalltalk tools debugger new process: process controller: nil context: context. debugger stack expand. ] ifCurtailed: [ process terminate] I do not get any extra process hanging around. now if I do | context process | context := [ 20 factorial ] asContext. process := Process forContext: context priority: Processor userInterruptPriority. [ debugger := Smalltalk tools debugger new process: process controller: nil context: context. debugger stack expand. Transcript show: debugger stack selectedIndex ] ifCurtailed: [ process terminate] But then when I do | context process debuggerg | context := [ 20 factorial ] asContext. process := Process forContext: context priority: Processor userInterruptPriority. [ debugger := Smalltalk tools debugger new process: process controller: nil context: context. debugger stack expand. Transcript show: debugger stack selectedIndex; cr. ] ensure: [ process terminate] I get processes stuck trying to open the log fiel ro something like that. Now I do not understand because when I ask the setter to stack (to get what is set in this variable) the system tells me that there is no store. Stef On 03 Apr 2014, at 20:49, Pharo4Stef <pharo4Stef@free.fr> wrote:
even using ensure: to make sure that the process is terminated it is not really working. I have the impression that there is a problem and that the tests does not really finishes but this is really difficult to debug.
Hi guys
I need your brain cells.
When I execute the test
testBasic | context process debugger printedString | context := [ 20 factorial ] asContext.
process := Process forContext: context priority: Processor userInterruptPriority.
debugger := Smalltalk tools debugger new process: process controller: nil context: context. debugger stack expand.
self assert: debugger stack selectedIndex = 1. printedString := OpalCompiler isActive ifTrue: [ '[ 20 factorial ] in DebuggerTest>>testBasic'] ifFalse: [ '[...] in DebuggerTest>>testBasic' ]. self assert: debugger stack selectedItem printString = printedString.
debugger send. debugger send. self assert: debugger code getText = (Integer>>#factorial) sourceCode. self assert: debugger stack selectedItem printString = 'SmallInteger(Integer)>>factorial'.
two times my image (latest get totally unusable). I thought that may be the process should be terminated so I added
process terminate
But nothing changes. I tried to debug the code but not chance. I tried self halt after [ 20 factorial ] asContext.
I tried to execute the beginning in a workspace and not as a test to eliminate problem. But again no chance.
So did I miss something obvious?
Stef
| context process debugger | context := [ 20 factorial ] asContext. process := Process forContext: context priority: Processor userInterruptPriority. [ debugger := Smalltalk tools debugger new process: process controller: nil context: context. Transcript show: debugger stack class ; cr ] ensure: [ process terminate] When I look at some of the stuck processes SpecDebugger>>initializePresenter super initializePresenter. self flag: 'some of this logic could be moved to the stack widget'. self flag: 'The toolbar should not be updated when the list changes, but when an action is perormed.'. self stack whenListChanged: [ :aList | aList isEmpty ifFalse: [ self stack setSelectedItem: aList first ]. "Updating the toolbar will result in changing the button widgets. If the widget hasn't been opened, there will be no spec, which leads to an error." self spec ifNotNil: [ self updateToolbar ] ]. self stack whenSelectedItemChanged: [:aContext | self updateCodeFromContext: aContext. self updateInspectorsFromContext: aContext. self stack updateForSelectionChanged ]. self contextInspector initializeAutoRefresh. ^^^^^^^^^^^^^^^^^^^^^^^^^^^ And initializeAutoRefresh does not exist in the latest image. I have no idea why the debugger may work may be this method is not used at all. Can somebody else confirm because I have the impression to fall into a rat nest. stef
ok now I understand: an endless loop inside the debugger creation. I do not understand why we did not address it with clement because we open the debugger and other when we fixed the logic of the inspector (to avoid polling refresh). Stef On 03 Apr 2014, at 21:13, Pharo4Stef <pharo4Stef@free.fr> wrote:
| context process debugger | context := [ 20 factorial ] asContext.
process := Process forContext: context priority: Processor userInterruptPriority. [ debugger := Smalltalk tools debugger new process: process controller: nil context: context. Transcript show: debugger stack class ; cr ] ensure: [ process terminate]
When I look at some of the stuck processes
SpecDebugger>>initializePresenter super initializePresenter. self flag: 'some of this logic could be moved to the stack widget'. self flag: 'The toolbar should not be updated when the list changes, but when an action is perormed.'. self stack whenListChanged: [ :aList | aList isEmpty ifFalse: [ self stack setSelectedItem: aList first ]. "Updating the toolbar will result in changing the button widgets. If the widget hasn't been opened, there will be no spec, which leads to an error." self spec ifNotNil: [ self updateToolbar ] ].
self stack whenSelectedItemChanged: [:aContext | self updateCodeFromContext: aContext. self updateInspectorsFromContext: aContext. self stack updateForSelectionChanged ].
self contextInspector initializeAutoRefresh.
^^^^^^^^^^^^^^^^^^^^^^^^^^^
And initializeAutoRefresh does not exist in the latest image. I have no idea why the debugger may work may be this method is not used at all.
Can somebody else confirm because I have the impression to fall into a rat nest. stef
Hey, I remembered removing the initializeAutoRefresh code from the debugger. Perhaps I didn't commit that package. Or I forgot this one. 2014-04-03 12:34 GMT-07:00 Pharo4Stef <pharo4Stef@free.fr>:
ok now I understand: an endless loop inside the debugger creation. I do not understand why we did not address it with clement because we open the debugger and other when we fixed the logic of the inspector (to avoid polling refresh).
Stef On 03 Apr 2014, at 21:13, Pharo4Stef <pharo4Stef@free.fr> wrote:
| context process debugger | context := [ 20 factorial ] asContext.
process := Process forContext: context priority: Processor userInterruptPriority. [ debugger := Smalltalk tools debugger new process: process controller: nil context: context. Transcript show: debugger stack class ; cr ] ensure: [ process terminate]
When I look at some of the stuck processes
SpecDebugger>>initializePresenter super initializePresenter. self flag: 'some of this logic could be moved to the stack widget'. self flag: 'The toolbar should not be updated when the list
changes, but when an action is perormed.'.
self stack whenListChanged: [ :aList | aList isEmpty ifFalse: [ self stack setSelectedItem: aList
first ].
"Updating the toolbar will result in changing the button
widgets.
If the widget hasn't been opened, there will be no spec,
which leads to an error."
self spec ifNotNil: [ self updateToolbar ] ].
self stack whenSelectedItemChanged: [:aContext | self updateCodeFromContext: aContext. self updateInspectorsFromContext: aContext. self stack updateForSelectionChanged ].
self contextInspector initializeAutoRefresh.
^^^^^^^^^^^^^^^^^^^^^^^^^^^
And initializeAutoRefresh does not exist in the latest image. I have no idea why the debugger may work may be this method is not used
at all.
Can somebody else confirm because I have the impression to fall into a
rat nest.
stef
Iâm sorry but I will stop working on this issue since I do not have time for pharo anymore this week and the next one. Apparently Iâm the only one to care about this bogus logic so let it be but be prepared to have too many hanging process around. Stef
Hey,
I remembered removing the initializeAutoRefresh code from the debugger. Perhaps I didn't commit that package. Or I forgot this one.
2014-04-03 12:34 GMT-07:00 Pharo4Stef <pharo4Stef@free.fr>: ok now I understand: an endless loop inside the debugger creation. I do not understand why we did not address it with clement because we open the debugger and other when we fixed the logic of the inspector (to avoid polling refresh).
Stef On 03 Apr 2014, at 21:13, Pharo4Stef <pharo4Stef@free.fr> wrote:
| context process debugger | context := [ 20 factorial ] asContext.
process := Process forContext: context priority: Processor userInterruptPriority. [ debugger := Smalltalk tools debugger new process: process controller: nil context: context. Transcript show: debugger stack class ; cr ] ensure: [ process terminate]
When I look at some of the stuck processes
SpecDebugger>>initializePresenter super initializePresenter. self flag: 'some of this logic could be moved to the stack widget'. self flag: 'The toolbar should not be updated when the list changes, but when an action is perormed.'. self stack whenListChanged: [ :aList | aList isEmpty ifFalse: [ self stack setSelectedItem: aList first ]. "Updating the toolbar will result in changing the button widgets. If the widget hasn't been opened, there will be no spec, which leads to an error." self spec ifNotNil: [ self updateToolbar ] ].
self stack whenSelectedItemChanged: [:aContext | self updateCodeFromContext: aContext. self updateInspectorsFromContext: aContext. self stack updateForSelectionChanged ].
self contextInspector initializeAutoRefresh.
^^^^^^^^^^^^^^^^^^^^^^^^^^^
And initializeAutoRefresh does not exist in the latest image. I have no idea why the debugger may work may be this method is not used at all.
Can somebody else confirm because I have the impression to fall into a rat nest. stef
It is hard for everyone to get a complex issue cleanly integrated. On 04 Apr 2014, at 08:30, Pharo4Stef <pharo4Stef@free.fr> wrote:
Iâm sorry but I will stop working on this issue since I do not have time for pharo anymore this week and the next one. Apparently Iâm the only one to care about this bogus logic so let it be but be prepared to have too many hanging process around. Stef
Hey,
I remembered removing the initializeAutoRefresh code from the debugger. Perhaps I didn't commit that package. Or I forgot this one.
2014-04-03 12:34 GMT-07:00 Pharo4Stef <pharo4Stef@free.fr>: ok now I understand: an endless loop inside the debugger creation. I do not understand why we did not address it with clement because we open the debugger and other when we fixed the logic of the inspector (to avoid polling refresh).
Stef On 03 Apr 2014, at 21:13, Pharo4Stef <pharo4Stef@free.fr> wrote:
| context process debugger | context := [ 20 factorial ] asContext.
process := Process forContext: context priority: Processor userInterruptPriority. [ debugger := Smalltalk tools debugger new process: process controller: nil context: context. Transcript show: debugger stack class ; cr ] ensure: [ process terminate]
When I look at some of the stuck processes
SpecDebugger>>initializePresenter super initializePresenter. self flag: 'some of this logic could be moved to the stack widget'. self flag: 'The toolbar should not be updated when the list changes, but when an action is perormed.'. self stack whenListChanged: [ :aList | aList isEmpty ifFalse: [ self stack setSelectedItem: aList first ]. "Updating the toolbar will result in changing the button widgets. If the widget hasn't been opened, there will be no spec, which leads to an error." self spec ifNotNil: [ self updateToolbar ] ].
self stack whenSelectedItemChanged: [:aContext | self updateCodeFromContext: aContext. self updateInspectorsFromContext: aContext. self stack updateForSelectionChanged ].
self contextInspector initializeAutoRefresh.
^^^^^^^^^^^^^^^^^^^^^^^^^^^
And initializeAutoRefresh does not exist in the latest image. I have no idea why the debugger may work may be this method is not used at all.
Can somebody else confirm because I have the impression to fall into a rat nest. stef
I tried on my machine in latest image and no matter how many times I run this test, this test still passes and I don't notice any slowdown nor image freeze. But I see the hanging processes. Adding 'process terminate' at the end works for me. On 3 avr. 2014, at 19:41, Pharo4Stef <pharo4Stef@free.fr> wrote:
Hi guys
I need your brain cells.
When I execute the test
testBasic | context process debugger printedString | context := [ 20 factorial ] asContext.
process := Process forContext: context priority: Processor userInterruptPriority.
debugger := Smalltalk tools debugger new process: process controller: nil context: context. debugger stack expand.
self assert: debugger stack selectedIndex = 1. printedString := OpalCompiler isActive ifTrue: [ '[ 20 factorial ] in DebuggerTest>>testBasic'] ifFalse: [ '[...] in DebuggerTest>>testBasic' ]. self assert: debugger stack selectedItem printString = printedString.
debugger send. debugger send. self assert: debugger code getText = (Integer>>#factorial) sourceCode. self assert: debugger stack selectedItem printString = 'SmallInteger(Integer)>>factorial'.
two times my image (latest get totally unusable). I thought that may be the process should be terminated so I added
process terminate
But nothing changes. I tried to debug the code but not chance. I tried self halt after [ 20 factorial ] asContext.
I tried to execute the beginning in a workspace and not as a test to eliminate problem. But again no chance.
So did I miss something obvious?
Stef
Thanks camille apparently I restarted from a clean image but may be I merged. Could you try loading the latest version of 12460 and let me know? On 04 Apr 2014, at 09:21, Camille Teruel <camille.teruel@gmail.com> wrote:
I tried on my machine in latest image and no matter how many times I run this test, this test still passes and I don't notice any slowdown nor image freeze. But I see the hanging processes. Adding 'process terminate' at the end works for me.
On 3 avr. 2014, at 19:41, Pharo4Stef <pharo4Stef@free.fr> wrote:
Hi guys
I need your brain cells.
When I execute the test
testBasic | context process debugger printedString | context := [ 20 factorial ] asContext.
process := Process forContext: context priority: Processor userInterruptPriority.
debugger := Smalltalk tools debugger new process: process controller: nil context: context. debugger stack expand.
self assert: debugger stack selectedIndex = 1. printedString := OpalCompiler isActive ifTrue: [ '[ 20 factorial ] in DebuggerTest>>testBasic'] ifFalse: [ '[...] in DebuggerTest>>testBasic' ]. self assert: debugger stack selectedItem printString = printedString.
debugger send. debugger send. self assert: debugger code getText = (Integer>>#factorial) sourceCode. self assert: debugger stack selectedItem printString = 'SmallInteger(Integer)>>factorial'.
two times my image (latest get totally unusable). I thought that may be the process should be terminated so I added
process terminate
But nothing changes. I tried to debug the code but not chance. I tried self halt after [ 20 factorial ] asContext.
I tried to execute the beginning in a workspace and not as a test to eliminate problem. But again no chance.
So did I miss something obvious?
Stef
On 4 avr. 2014, at 12:37, Pharo4Stef <pharo4Stef@free.fr> wrote:
Thanks camille apparently I restarted from a clean image but may be I merged. Could you try loading the latest version of 12460 and let me know?
It works, but we still need to add 'process terminate' at the end. I open another bug entry (since it is not related to issue 12460).
On 04 Apr 2014, at 09:21, Camille Teruel <camille.teruel@gmail.com> wrote:
I tried on my machine in latest image and no matter how many times I run this test, this test still passes and I don't notice any slowdown nor image freeze. But I see the hanging processes. Adding 'process terminate' at the end works for me.
On 3 avr. 2014, at 19:41, Pharo4Stef <pharo4Stef@free.fr> wrote:
Hi guys
I need your brain cells.
When I execute the test
testBasic | context process debugger printedString | context := [ 20 factorial ] asContext.
process := Process forContext: context priority: Processor userInterruptPriority.
debugger := Smalltalk tools debugger new process: process controller: nil context: context. debugger stack expand.
self assert: debugger stack selectedIndex = 1. printedString := OpalCompiler isActive ifTrue: [ '[ 20 factorial ] in DebuggerTest>>testBasic'] ifFalse: [ '[...] in DebuggerTest>>testBasic' ]. self assert: debugger stack selectedItem printString = printedString.
debugger send. debugger send. self assert: debugger code getText = (Integer>>#factorial) sourceCode. self assert: debugger stack selectedItem printString = 'SmallInteger(Integer)>>factorial'.
two times my image (latest get totally unusable). I thought that may be the process should be terminated so I added
process terminate
But nothing changes. I tried to debug the code but not chance. I tried self halt after [ 20 factorial ] asContext.
I tried to execute the beginning in a workspace and not as a test to eliminate problem. But again no chance.
So did I miss something obvious?
Stef
Fix in inbox https://pharo.fogbugz.com/f/cases/13170/ On 4 avr. 2014, at 12:46, Camille Teruel <camille.teruel@gmail.com> wrote:
On 4 avr. 2014, at 12:37, Pharo4Stef <pharo4Stef@free.fr> wrote:
Thanks camille apparently I restarted from a clean image but may be I merged. Could you try loading the latest version of 12460 and let me know?
It works, but we still need to add 'process terminate' at the end. I open another bug entry (since it is not related to issue 12460).
On 04 Apr 2014, at 09:21, Camille Teruel <camille.teruel@gmail.com> wrote:
I tried on my machine in latest image and no matter how many times I run this test, this test still passes and I don't notice any slowdown nor image freeze. But I see the hanging processes. Adding 'process terminate' at the end works for me.
On 3 avr. 2014, at 19:41, Pharo4Stef <pharo4Stef@free.fr> wrote:
Hi guys
I need your brain cells.
When I execute the test
testBasic | context process debugger printedString | context := [ 20 factorial ] asContext.
process := Process forContext: context priority: Processor userInterruptPriority.
debugger := Smalltalk tools debugger new process: process controller: nil context: context. debugger stack expand.
self assert: debugger stack selectedIndex = 1. printedString := OpalCompiler isActive ifTrue: [ '[ 20 factorial ] in DebuggerTest>>testBasic'] ifFalse: [ '[...] in DebuggerTest>>testBasic' ]. self assert: debugger stack selectedItem printString = printedString.
debugger send. debugger send. self assert: debugger code getText = (Integer>>#factorial) sourceCode. self assert: debugger stack selectedItem printString = 'SmallInteger(Integer)>>factorial'.
two times my image (latest get totally unusable). I thought that may be the process should be terminated so I added
process terminate
But nothing changes. I tried to debug the code but not chance. I tried self halt after [ 20 factorial ] asContext.
I tried to execute the beginning in a workspace and not as a test to eliminate problem. But again no chance.
So did I miss something obvious?
Stef
Hi Stef, I think it is because forContext:priority: does not schedule the process, just creates it. The debugger code steps the process but after stepping the process is still not runnable. So the process terminate is unnecessary; the process should not have been added to the run queue and should juts be GCed. Since it is not the question is what refers to the process after the test has run. To debug, I would rewrite the test as such: testBasic | process debugger printedString | process := Process forContext: [ 20 factorial ] asContext priority: Processor activePriority. debugger := Smalltalk tools debugger new process: process controller: nil context: context. debugger stack expand. self assert: debugger stack selectedIndex = 1. printedString := OpalCompiler isActive ifTrue: [ '[ 20 factorial ] in DebuggerTest>>testBasic'] ifFalse: [ '[...] in DebuggerTest>>testBasic' ]. self assert: debugger stack selectedItem printString = printedString. debugger send. debugger send. self assert: debugger code getText = (Integer>>#factorial) sourceCode. self assert: debugger stack selectedItem printString = 'SmallInteger(Integer)>>factorial'. ^process and then chase pointers on the result to see what is holding onto the process. Sicne the process is never runnable there's no need to set its priority to anything special. However, one should also be able to replace the "process terminate" with "process resume" to get it to run to termination (provided its priority stays at Processor userInterruptPriority). HTH On Thu, Apr 3, 2014 at 10:41 AM, Pharo4Stef <pharo4Stef@free.fr> wrote:
Hi guys
I need your brain cells.
When I execute the test
testBasic | context process debugger printedString | context := [ 20 factorial ] asContext.
process := Process forContext: context priority: Processor userInterruptPriority.
debugger := Smalltalk tools debugger new process: process controller: nil context: context. debugger stack expand.
self assert: debugger stack selectedIndex = 1. printedString := OpalCompiler isActive ifTrue: [ '[ 20 factorial ] in DebuggerTest>>testBasic'] ifFalse: [ '[...] in DebuggerTest>>testBasic' ]. self assert: debugger stack selectedItem printString = printedString.
debugger send. debugger send. self assert: debugger code getText = (Integer>>#factorial) sourceCode. self assert: debugger stack selectedItem printString = 'SmallInteger(Integer)>>factorial'.
two times my image (latest get totally unusable). I thought that may be the process should be terminated so I added
process terminate
But nothing changes. I tried to debug the code but not chance. I tried self halt after [ 20 factorial ] asContext.
I tried to execute the beginning in a workspace and not as a test to eliminate problem. But again no chance.
So did I miss something obvious?
Stef
-- best, Eliot
On Sat, Apr 5, 2014 at 10:30 AM, Eliot Miranda <eliot.miranda@gmail.com>wrote:
Hi Stef,
I think it is because forContext:priority: does not schedule the process, just creates it. The debugger code steps the process but after stepping the process is still not runnable. So the process terminate is unnecessary; the process should not have been added to the run queue and should juts be GCed. Since it is not the question is what refers to the process after the test has run.
(Since it is not GCed, the question is "what refers to the process after the test has run?"). To debug, I would rewrite the test as such:
testBasic | process debugger printedString | process := Process forContext: [ 20 factorial ] asContext priority: Processor activePriority.
debugger := Smalltalk tools debugger new process: process controller: nil context: context. debugger stack expand.
self assert: debugger stack selectedIndex = 1. printedString := OpalCompiler isActive ifTrue: [ '[ 20 factorial ] in DebuggerTest>>testBasic'] ifFalse: [ '[...] in DebuggerTest>>testBasic' ]. self assert: debugger stack selectedItem printString = printedString.
debugger send. debugger send. self assert: debugger code getText = (Integer>>#factorial) sourceCode. self assert: debugger stack selectedItem printString = 'SmallInteger(Integer)>>factorial'.
^process
and then chase pointers on the result to see what is holding onto the process. Sicne the process is never runnable there's no need to set its priority to anything special.
However, one should also be able to replace the "process terminate" with "process resume" to get it to run to termination (provided its priority stays at Processor userInterruptPriority).
HTH
On Thu, Apr 3, 2014 at 10:41 AM, Pharo4Stef <pharo4Stef@free.fr> wrote:
Hi guys
I need your brain cells.
When I execute the test
testBasic | context process debugger printedString | context := [ 20 factorial ] asContext.
process := Process forContext: context priority: Processor userInterruptPriority.
debugger := Smalltalk tools debugger new process: process controller: nil context: context. debugger stack expand.
self assert: debugger stack selectedIndex = 1. printedString := OpalCompiler isActive ifTrue: [ '[ 20 factorial ] in DebuggerTest>>testBasic'] ifFalse: [ '[...] in DebuggerTest>>testBasic' ]. self assert: debugger stack selectedItem printString = printedString.
debugger send. debugger send. self assert: debugger code getText = (Integer>>#factorial) sourceCode. self assert: debugger stack selectedItem printString = 'SmallInteger(Integer)>>factorial'.
two times my image (latest get totally unusable). I thought that may be the process should be terminated so I added
process terminate
But nothing changes. I tried to debug the code but not chance. I tried self halt after [ 20 factorial ] asContext.
I tried to execute the beginning in a workspace and not as a test to eliminate problem. But again no chance.
So did I miss something obvious?
Stef
-- best, Eliot
-- best, Eliot
In fact there was an error in the debugger code => endless loop in another thread it was strange because the test was not returning On 05 Apr 2014, at 19:30, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Stef,
I think it is because forContext:priority: does not schedule the process, just creates it. The debugger code steps the process but after stepping the process is still not runnable. So the process terminate is unnecessary; the process should not have been added to the run queue and should juts be GCed. Since it is not the question is what refers to the process after the test has run.
To debug, I would rewrite the test as such:
testBasic | process debugger printedString | process := Process forContext: [ 20 factorial ] asContext priority: Processor activePriority.
debugger := Smalltalk tools debugger new process: process controller: nil context: context. debugger stack expand.
self assert: debugger stack selectedIndex = 1. printedString := OpalCompiler isActive ifTrue: [ '[ 20 factorial ] in DebuggerTest>>testBasic'] ifFalse: [ '[...] in DebuggerTest>>testBasic' ]. self assert: debugger stack selectedItem printString = printedString.
debugger send. debugger send. self assert: debugger code getText = (Integer>>#factorial) sourceCode. self assert: debugger stack selectedItem printString = 'SmallInteger(Integer)>>factorial'.
^process
and then chase pointers on the result to see what is holding onto the process. Sicne the process is never runnable there's no need to set its priority to anything special.
However, one should also be able to replace the "process terminate" with "process resume" to get it to run to termination (provided its priority stays at Processor userInterruptPriority).
HTH
On Thu, Apr 3, 2014 at 10:41 AM, Pharo4Stef <pharo4Stef@free.fr> wrote: Hi guys
I need your brain cells.
When I execute the test
testBasic | context process debugger printedString | context := [ 20 factorial ] asContext.
process := Process forContext: context priority: Processor userInterruptPriority.
debugger := Smalltalk tools debugger new process: process controller: nil context: context. debugger stack expand.
self assert: debugger stack selectedIndex = 1. printedString := OpalCompiler isActive ifTrue: [ '[ 20 factorial ] in DebuggerTest>>testBasic'] ifFalse: [ '[...] in DebuggerTest>>testBasic' ]. self assert: debugger stack selectedItem printString = printedString.
debugger send. debugger send. self assert: debugger code getText = (Integer>>#factorial) sourceCode. self assert: debugger stack selectedItem printString = 'SmallInteger(Integer)>>factorial'.
two times my image (latest get totally unusable). I thought that may be the process should be terminated so I added
process terminate
But nothing changes. I tried to debug the code but not chance. I tried self halt after [ 20 factorial ] asContext.
I tried to execute the beginning in a workspace and not as a test to eliminate problem. But again no chance.
So did I miss something obvious?
Stef
-- best, Eliot
participants (5)
-
Camille Teruel -
Clément Bera -
Eliot Miranda -
Pharo4Stef -
Sven Van Caekenberghe