Re: Wrong method source pointer in Squeak5.2

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

Re: Wrong method source pointer in Squeak5.2

Max Leske

Hi Nicolas, hi Dave,

I did some more digging and found that the problem is actually present in (probably) every 5.2 image. It can easily be found by opening a fresh image and evaluating "self halt". In the debugger, click on "full stack" and scroll down to the first context (BlockClosure>>newProcess) and click on the entry. This will cause a SyntaxError dialog to open.

Closing both the SyntaxError dialog and the debugger makes the problem go away. The reason for this appears to be that opening the debugger as caused the UI process to be replaced with a new instance (the old instance was the one opened in the debugger). You can see this easily by evaluating "[ self halt ] fork" and clicking on the first stack frame, which will not cause the SyntaxError dialog to open. Alternatively, you could evaluate "Project current spawnNewProcessAndTerminateOld: true".

What I've discovered so far is that the problematic contexts in the UI process (there are multiple) are not the CompiledMethod instances installed in the respective classes. You can verify this by comparing "(BlockClosure>>#newProcess) identityHash" with the hash of the method in the context (select the third last frame, inspect the "thisContext" variable and evaluate "self sender sender method identityHash in that inspector"). After the UI process has been replaced those identity hashes are equal again.
The information in the "old/bad" CompiledMethod obviously points to a bad offset in the changes file.

I also now understand why this only affects the one specific test case: the test accesses the method node for each context in the current process, i.e. the UI process, which includes the bad contexts (access to the method node causes decompilation of the method which causes source access).

Please let me know when you've found a solution and also if I can be of more help.

Cheers,
Max

Hi,

We have an issue in Seaside where a loaded test method holds a bad source pointer. We only noticed because this method accesses the debugger map.

How to reproduce:

clone SmalltalkCI: git clone [hidden email]:hpi-swa/smalltalkCI.git
clone Seaside: git clone [hidden email]:SeasideSt/Seaside.git; git checkout 9cb54a7b14cd254ef318294905c4e8dda8dd9f79
install Seaside in Squeak5.2: <path to SmalltalkCI>/run.sh --headful -s Squeak-5.2 <path to Seaside>/.smalltalk.ston
Run the test WAPharoDebuggerTest>>testNamedTempAt and you'll see a debugger pop up for an UndeclaredVariable. The source lookup is performed in the changes file but in the middle of a chunk of binary (font) data.
I can can only speculate that some of that binary data introduces random chunks which messes with the offsets.

We're adding a workaround for that particular test for now.

Let me know if I can help track down the issue.

Cheers,
Max



Reply | Threaded
Open this post in threaded view
|

Re: Wrong method source pointer in Squeak5.2

marcel.taeumel
Hi, there.

At the moment, "SyntaxError" is not in harmony with the rest of exception handling and debugging. I do have some notes and ideas on how to improve that. Maybe these issues will go away then, too. :-)

I think, we miss a concept to have any kind of interactive tooling for any kind of exception. Right now, there is Debugger and SyntaxError. Etoys has an "Ooops!" dialog. :-) There could be more. Some fancy, some just informative.

Best,
Marcel

Am 13.01.2019 07:59:01 schrieb Max Leske <[hidden email]>:

Hi Nicolas, hi Dave,

I did some more digging and found that the problem is actually present in (probably) every 5.2 image. It can easily be found by opening a fresh image and evaluating "self halt". In the debugger, click on "full stack" and scroll down to the first context (BlockClosure>>newProcess) and click on the entry. This will cause a SyntaxError dialog to open.

Closing both the SyntaxError dialog and the debugger makes the problem go away. The reason for this appears to be that opening the debugger as caused the UI process to be replaced with a new instance (the old instance was the one opened in the debugger). You can see this easily by evaluating "[ self halt ] fork" and clicking on the first stack frame, which will not cause the SyntaxError dialog to open. Alternatively, you could evaluate "Project current spawnNewProcessAndTerminateOld: true".

What I've discovered so far is that the problematic contexts in the UI process (there are multiple) are not the CompiledMethod instances installed in the respective classes. You can verify this by comparing "(BlockClosure>>#newProcess) identityHash" with the hash of the method in the context (select the third last frame, inspect the "thisContext" variable and evaluate "self sender sender method identityHash in that inspector"). After the UI process has been replaced those identity hashes are equal again.
The information in the "old/bad" CompiledMethod obviously points to a bad offset in the changes file.

I also now understand why this only affects the one specific test case: the test accesses the method node for each context in the current process, i.e. the UI process, which includes the bad contexts (access to the method node causes decompilation of the method which causes source access).

Please let me know when you've found a solution and also if I can be of more help.

Cheers,
Max

Hi,

We have an issue in Seaside where a loaded test method holds a bad source pointer. We only noticed because this method accesses the debugger map.

How to reproduce:

clone SmalltalkCI: git clone [hidden email]:hpi-swa/smalltalkCI.git
clone Seaside: git clone [hidden email]:SeasideSt/Seaside.git; git checkout 9cb54a7b14cd254ef318294905c4e8dda8dd9f79
install Seaside in Squeak5.2: <path to SmalltalkCI>/run.sh --headful -s Squeak-5.2 <path to Seaside>/.smalltalk.ston
Run the test WAPharoDebuggerTest>>testNamedTempAt and you'll see a debugger pop up for an UndeclaredVariable. The source lookup is performed in the changes file but in the middle of a chunk of binary (font) data.
I can can only speculate that some of that binary data introduces random chunks which messes with the offsets.

We're adding a workaround for that particular test for now.

Let me know if I can help track down the issue.

Cheers,
Max



Reply | Threaded
Open this post in threaded view
|

Re: Wrong method source pointer in Squeak5.2

Nicolas Cellier
Thanks Max,
good find!
There is certainly a problem in the release procedures.
We have to make sure that the CompiledMethod running are the one installed.
And we should restart the Process for which it's not the case.
How to proceed next?
I think it's a good subject to discuss in Squeak board.

Le dim. 13 janv. 2019 à 10:49, Marcel Taeumel <[hidden email]> a écrit :
Hi, there.

At the moment, "SyntaxError" is not in harmony with the rest of exception handling and debugging. I do have some notes and ideas on how to improve that. Maybe these issues will go away then, too. :-)

I think, we miss a concept to have any kind of interactive tooling for any kind of exception. Right now, there is Debugger and SyntaxError. Etoys has an "Ooops!" dialog. :-) There could be more. Some fancy, some just informative.

Best,
Marcel

Am 13.01.2019 07:59:01 schrieb Max Leske <[hidden email]>:

Hi Nicolas, hi Dave,

I did some more digging and found that the problem is actually present in (probably) every 5.2 image. It can easily be found by opening a fresh image and evaluating "self halt". In the debugger, click on "full stack" and scroll down to the first context (BlockClosure>>newProcess) and click on the entry. This will cause a SyntaxError dialog to open.

Closing both the SyntaxError dialog and the debugger makes the problem go away. The reason for this appears to be that opening the debugger as caused the UI process to be replaced with a new instance (the old instance was the one opened in the debugger). You can see this easily by evaluating "[ self halt ] fork" and clicking on the first stack frame, which will not cause the SyntaxError dialog to open. Alternatively, you could evaluate "Project current spawnNewProcessAndTerminateOld: true".

What I've discovered so far is that the problematic contexts in the UI process (there are multiple) are not the CompiledMethod instances installed in the respective classes. You can verify this by comparing "(BlockClosure>>#newProcess) identityHash" with the hash of the method in the context (select the third last frame, inspect the "thisContext" variable and evaluate "self sender sender method identityHash in that inspector"). After the UI process has been replaced those identity hashes are equal again.
The information in the "old/bad" CompiledMethod obviously points to a bad offset in the changes file.

I also now understand why this only affects the one specific test case: the test accesses the method node for each context in the current process, i.e. the UI process, which includes the bad contexts (access to the method node causes decompilation of the method which causes source access).

Please let me know when you've found a solution and also if I can be of more help.

Cheers,
Max

Hi,

We have an issue in Seaside where a loaded test method holds a bad source pointer. We only noticed because this method accesses the debugger map.

How to reproduce:

clone SmalltalkCI: git clone [hidden email]:hpi-swa/smalltalkCI.git
clone Seaside: git clone [hidden email]:SeasideSt/Seaside.git; git checkout 9cb54a7b14cd254ef318294905c4e8dda8dd9f79
install Seaside in Squeak5.2: <path to SmalltalkCI>/run.sh --headful -s Squeak-5.2 <path to Seaside>/.smalltalk.ston
Run the test WAPharoDebuggerTest>>testNamedTempAt and you'll see a debugger pop up for an UndeclaredVariable. The source lookup is performed in the changes file but in the middle of a chunk of binary (font) data.
I can can only speculate that some of that binary data introduces random chunks which messes with the offsets.

We're adding a workaround for that particular test for now.

Let me know if I can help track down the issue.

Cheers,
Max




Reply | Threaded
Open this post in threaded view
|

Re: Wrong method source pointer in Squeak5.2

Nicolas Cellier
Hi Max,
is it the 32bits or 64bits image?

Le dim. 13 janv. 2019 à 21:27, Nicolas Cellier <[hidden email]> a écrit :
Thanks Max,
good find!
There is certainly a problem in the release procedures.
We have to make sure that the CompiledMethod running are the one installed.
And we should restart the Process for which it's not the case.
How to proceed next?
I think it's a good subject to discuss in Squeak board.

Le dim. 13 janv. 2019 à 10:49, Marcel Taeumel <[hidden email]> a écrit :
Hi, there.

At the moment, "SyntaxError" is not in harmony with the rest of exception handling and debugging. I do have some notes and ideas on how to improve that. Maybe these issues will go away then, too. :-)

I think, we miss a concept to have any kind of interactive tooling for any kind of exception. Right now, there is Debugger and SyntaxError. Etoys has an "Ooops!" dialog. :-) There could be more. Some fancy, some just informative.

Best,
Marcel

Am 13.01.2019 07:59:01 schrieb Max Leske <[hidden email]>:

Hi Nicolas, hi Dave,

I did some more digging and found that the problem is actually present in (probably) every 5.2 image. It can easily be found by opening a fresh image and evaluating "self halt". In the debugger, click on "full stack" and scroll down to the first context (BlockClosure>>newProcess) and click on the entry. This will cause a SyntaxError dialog to open.

Closing both the SyntaxError dialog and the debugger makes the problem go away. The reason for this appears to be that opening the debugger as caused the UI process to be replaced with a new instance (the old instance was the one opened in the debugger). You can see this easily by evaluating "[ self halt ] fork" and clicking on the first stack frame, which will not cause the SyntaxError dialog to open. Alternatively, you could evaluate "Project current spawnNewProcessAndTerminateOld: true".

What I've discovered so far is that the problematic contexts in the UI process (there are multiple) are not the CompiledMethod instances installed in the respective classes. You can verify this by comparing "(BlockClosure>>#newProcess) identityHash" with the hash of the method in the context (select the third last frame, inspect the "thisContext" variable and evaluate "self sender sender method identityHash in that inspector"). After the UI process has been replaced those identity hashes are equal again.
The information in the "old/bad" CompiledMethod obviously points to a bad offset in the changes file.

I also now understand why this only affects the one specific test case: the test accesses the method node for each context in the current process, i.e. the UI process, which includes the bad contexts (access to the method node causes decompilation of the method which causes source access).

Please let me know when you've found a solution and also if I can be of more help.

Cheers,
Max

Hi,

We have an issue in Seaside where a loaded test method holds a bad source pointer. We only noticed because this method accesses the debugger map.

How to reproduce:

clone SmalltalkCI: git clone [hidden email]:hpi-swa/smalltalkCI.git
clone Seaside: git clone [hidden email]:SeasideSt/Seaside.git; git checkout 9cb54a7b14cd254ef318294905c4e8dda8dd9f79
install Seaside in Squeak5.2: <path to SmalltalkCI>/run.sh --headful -s Squeak-5.2 <path to Seaside>/.smalltalk.ston
Run the test WAPharoDebuggerTest>>testNamedTempAt and you'll see a debugger pop up for an UndeclaredVariable. The source lookup is performed in the changes file but in the middle of a chunk of binary (font) data.
I can can only speculate that some of that binary data introduces random chunks which messes with the offsets.

We're adding a workaround for that particular test for now.

Let me know if I can help track down the issue.

Cheers,
Max




Reply | Threaded
Open this post in threaded view
|

Re: Wrong method source pointer in Squeak5.2

Bert Freudenberg
In reply to this post by Nicolas Cellier
IMHO the ReleaseBuilder should restart all processes.

- Bert -

On Sun, Jan 13, 2019 at 12:27 PM Nicolas Cellier <[hidden email]> wrote:
Thanks Max,
good find!
There is certainly a problem in the release procedures.
We have to make sure that the CompiledMethod running are the one installed.
And we should restart the Process for which it's not the case.
How to proceed next?
I think it's a good subject to discuss in Squeak board.

Le dim. 13 janv. 2019 à 10:49, Marcel Taeumel <[hidden email]> a écrit :
Hi, there.

At the moment, "SyntaxError" is not in harmony with the rest of exception handling and debugging. I do have some notes and ideas on how to improve that. Maybe these issues will go away then, too. :-)

I think, we miss a concept to have any kind of interactive tooling for any kind of exception. Right now, there is Debugger and SyntaxError. Etoys has an "Ooops!" dialog. :-) There could be more. Some fancy, some just informative.

Best,
Marcel

Am 13.01.2019 07:59:01 schrieb Max Leske <[hidden email]>:

Hi Nicolas, hi Dave,

I did some more digging and found that the problem is actually present in (probably) every 5.2 image. It can easily be found by opening a fresh image and evaluating "self halt". In the debugger, click on "full stack" and scroll down to the first context (BlockClosure>>newProcess) and click on the entry. This will cause a SyntaxError dialog to open.

Closing both the SyntaxError dialog and the debugger makes the problem go away. The reason for this appears to be that opening the debugger as caused the UI process to be replaced with a new instance (the old instance was the one opened in the debugger). You can see this easily by evaluating "[ self halt ] fork" and clicking on the first stack frame, which will not cause the SyntaxError dialog to open. Alternatively, you could evaluate "Project current spawnNewProcessAndTerminateOld: true".

What I've discovered so far is that the problematic contexts in the UI process (there are multiple) are not the CompiledMethod instances installed in the respective classes. You can verify this by comparing "(BlockClosure>>#newProcess) identityHash" with the hash of the method in the context (select the third last frame, inspect the "thisContext" variable and evaluate "self sender sender method identityHash in that inspector"). After the UI process has been replaced those identity hashes are equal again.
The information in the "old/bad" CompiledMethod obviously points to a bad offset in the changes file.

I also now understand why this only affects the one specific test case: the test accesses the method node for each context in the current process, i.e. the UI process, which includes the bad contexts (access to the method node causes decompilation of the method which causes source access).

Please let me know when you've found a solution and also if I can be of more help.

Cheers,
Max

Hi,

We have an issue in Seaside where a loaded test method holds a bad source pointer. We only noticed because this method accesses the debugger map.

How to reproduce:

clone SmalltalkCI: git clone [hidden email]:hpi-swa/smalltalkCI.git
clone Seaside: git clone [hidden email]:SeasideSt/Seaside.git; git checkout 9cb54a7b14cd254ef318294905c4e8dda8dd9f79
install Seaside in Squeak5.2: <path to SmalltalkCI>/run.sh --headful -s Squeak-5.2 <path to Seaside>/.smalltalk.ston
Run the test WAPharoDebuggerTest>>testNamedTempAt and you'll see a debugger pop up for an UndeclaredVariable. The source lookup is performed in the changes file but in the middle of a chunk of binary (font) data.
I can can only speculate that some of that binary data introduces random chunks which messes with the offsets.

We're adding a workaround for that particular test for now.

Let me know if I can help track down the issue.

Cheers,
Max





Reply | Threaded
Open this post in threaded view
|

Re: Wrong method source pointer in Squeak5.2

Eliot Miranda-2
Hi Bert,

On Wed, Jan 16, 2019 at 1:24 PM Bert Freudenberg <[hidden email]> wrote:
IMHO the ReleaseBuilder should restart all processes.

And this is essential if there are any significant compiler changes (and there were with the inlining of repeat), because the system should be recompiled and for that to be effective all processes must be restarted.
 

- Bert -

On Sun, Jan 13, 2019 at 12:27 PM Nicolas Cellier <[hidden email]> wrote:
Thanks Max,
good find!
There is certainly a problem in the release procedures.
We have to make sure that the CompiledMethod running are the one installed.
And we should restart the Process for which it's not the case.
How to proceed next?
I think it's a good subject to discuss in Squeak board.

Le dim. 13 janv. 2019 à 10:49, Marcel Taeumel <[hidden email]> a écrit :
Hi, there.

At the moment, "SyntaxError" is not in harmony with the rest of exception handling and debugging. I do have some notes and ideas on how to improve that. Maybe these issues will go away then, too. :-)

I think, we miss a concept to have any kind of interactive tooling for any kind of exception. Right now, there is Debugger and SyntaxError. Etoys has an "Ooops!" dialog. :-) There could be more. Some fancy, some just informative.

Best,
Marcel

Am 13.01.2019 07:59:01 schrieb Max Leske <[hidden email]>:

Hi Nicolas, hi Dave,

I did some more digging and found that the problem is actually present in (probably) every 5.2 image. It can easily be found by opening a fresh image and evaluating "self halt". In the debugger, click on "full stack" and scroll down to the first context (BlockClosure>>newProcess) and click on the entry. This will cause a SyntaxError dialog to open.

Closing both the SyntaxError dialog and the debugger makes the problem go away. The reason for this appears to be that opening the debugger as caused the UI process to be replaced with a new instance (the old instance was the one opened in the debugger). You can see this easily by evaluating "[ self halt ] fork" and clicking on the first stack frame, which will not cause the SyntaxError dialog to open. Alternatively, you could evaluate "Project current spawnNewProcessAndTerminateOld: true".

What I've discovered so far is that the problematic contexts in the UI process (there are multiple) are not the CompiledMethod instances installed in the respective classes. You can verify this by comparing "(BlockClosure>>#newProcess) identityHash" with the hash of the method in the context (select the third last frame, inspect the "thisContext" variable and evaluate "self sender sender method identityHash in that inspector"). After the UI process has been replaced those identity hashes are equal again.
The information in the "old/bad" CompiledMethod obviously points to a bad offset in the changes file.

I also now understand why this only affects the one specific test case: the test accesses the method node for each context in the current process, i.e. the UI process, which includes the bad contexts (access to the method node causes decompilation of the method which causes source access).

Please let me know when you've found a solution and also if I can be of more help.

Cheers,
Max

Hi,

We have an issue in Seaside where a loaded test method holds a bad source pointer. We only noticed because this method accesses the debugger map.

How to reproduce:

clone SmalltalkCI: git clone [hidden email]:hpi-swa/smalltalkCI.git
clone Seaside: git clone [hidden email]:SeasideSt/Seaside.git; git checkout 9cb54a7b14cd254ef318294905c4e8dda8dd9f79
install Seaside in Squeak5.2: <path to SmalltalkCI>/run.sh --headful -s Squeak-5.2 <path to Seaside>/.smalltalk.ston
Run the test WAPharoDebuggerTest>>testNamedTempAt and you'll see a debugger pop up for an UndeclaredVariable. The source lookup is performed in the changes file but in the middle of a chunk of binary (font) data.
I can can only speculate that some of that binary data introduces random chunks which messes with the offsets.

We're adding a workaround for that particular test for now.

Let me know if I can help track down the issue.

Cheers,
Max






--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Wrong method source pointer in Squeak5.2

Max Leske
In reply to this post by Max Leske
Both. I have verified
http://files.squeak.org/5.2/Squeak5.2-18225-32bit/Squeak5.2-18225-32bit-201810190412-macOS.dmg 
and
http://files.squeak.org/5.2/Squeak5.2-18225-64bit/Squeak5.2-18225-64bit-201810190412-macOS.dmg.


On 17 Jan 2019, at 0:49, [hidden email]
wrote:

> Hi Max,
> is it the 32bits or 64bits image?
>
> Le dim. 13 janv. 2019 à 21:27, Nicolas Cellier <
> [hidden email]> a écrit :
>
>
>> Thanks Max,
>> good find!
>> There is certainly a problem in the release procedures.
>> We have to make sure that the CompiledMethod running are the one
>> installed.
>> And we should restart the Process for which it's not the case.
>> How to proceed next?
>> I think it's a good subject to discuss in Squeak board.
>>
>> Le dim. 13 janv. 2019 à 10:49, Marcel Taeumel
>> <[hidden email]> a
>> écrit :
>>
>
>>> Hi, there.
>>>
>>> At the moment, "SyntaxError" is not in harmony with the rest of
>>> exception handling and debugging. I do have some notes and ideas on
>>> how to
>>> improve that. Maybe these issues will go away then, too. :-)
>>>
>>> I think, we miss a concept to have any kind of interactive tooling
>>> for
>>> any kind of exception. Right now, there is Debugger and SyntaxError.
>>> Etoys
>>> has an "Ooops!" dialog. :-) There could be more. Some fancy, some
>>> just
>>> informative.
>>>
>>> Best,
>>> Marcel
>>>
>>> Am 13.01.2019 07:59:01 schrieb Max Leske <[hidden email]>:
>>>
>>> Hi Nicolas, hi Dave,
>>>
>>> I did some more digging and found that the problem is actually
>>> present in
>>> (probably) every 5.2 image. It can easily be found by opening a
>>> fresh image
>>> and evaluating "self halt". In the debugger, click on "full stack"
>>> and
>>> scroll down to the first context (BlockClosure>>newProcess) and
>>> click on
>>> the entry. This will cause a SyntaxError dialog to open.
>>>
>>> Closing both the SyntaxError dialog and the debugger makes the
>>> problem go
>>> away. The reason for this appears to be that opening the debugger as
>>> caused
>>> the UI process to be replaced with a new instance (the old instance
>>> was the
>>> one opened in the debugger). You can see this easily by evaluating
>>> "[ self
>>> halt ] fork" and clicking on the first stack frame, which will not
>>> cause
>>> the SyntaxError dialog to open. Alternatively, you could evaluate
>>> "Project
>>> current spawnNewProcessAndTerminateOld: true".
>>>
>>> What I've discovered so far is that the problematic contexts in the
>>> UI
>>> process (there are multiple) are *not* the CompiledMethod instances
>>> installed in the respective classes. You can verify this by
>>> comparing
>>> "(BlockClosure>>#newProcess) identityHash" with the hash of the
>>> method in
>>> the context (select the third last frame, inspect the "thisContext"
>>> variable and evaluate "self sender sender method identityHash in
>>> that
>>> inspector"). After the UI process has been replaced those identity
>>> hashes
>>> are equal again.
>>> The information in the "old/bad" CompiledMethod obviously points to
>>> a bad
>>> offset in the changes file.
>>>
>>> I also now understand why this only affects the one specific test
>>> case:
>>> the test accesses the method node for each context in the current
>>> process,
>>> i.e. the UI process, which includes the bad contexts (access to the
>>> method
>>> node causes decompilation of the method which causes source access).
>>>
>>> Please let me know when you've found a solution and also if I can be
>>> of
>>> more help.
>>>
>>> Cheers,
>>> Max
>>>
>>> Hi,
>>>
>>> We have an issue in Seaside where a loaded test method holds a bad
>>> source
>>> pointer. We only noticed because this method accesses the debugger
>>> map.
>>>
>>> How to reproduce:
>>>
>>> clone SmalltalkCI: git clone [hidden email]:hpi-swa/smalltalkCI.git
>>> clone Seaside: git clone [hidden email]:SeasideSt/Seaside.git; git
>>> checkout 9cb54a7b14cd254ef318294905c4e8dda8dd9f79
>>> install Seaside in Squeak5.2: <path to SmalltalkCI>/run.sh --headful
>>> -s
>>> Squeak-5.2 <path to Seaside>/.smalltalk.ston
>>> Run the test WAPharoDebuggerTest>>testNamedTempAt and you'll see a
>>> debugger pop up for an UndeclaredVariable. The source lookup is
>>> performed
>>> in the changes file but in the middle of a chunk of binary (font)
>>> data.
>>> I can can only speculate that some of that binary data introduces
>>> random
>>> chunks which messes with the offsets.
>>>
>>> We're adding a workaround for that particular test for now.
>>>
>>> Let me know if I can help track down the issue.
>>>
>>> Cheers,
>>> Max

Reply | Threaded
Open this post in threaded view
|

Re: Wrong method source pointer in Squeak5.2

marcel.taeumel
In reply to this post by Eliot Miranda-2
Hi, there.

At the moment, processes (should) restart themselves (implicitely) through #cleanUp:. Is there consent that we should make this more explicit in the ReleaseBuilder? If so, when? After condensing changes? After recompiling all?

Best,
Marcel

Am 16.01.2019 23:18:35 schrieb Eliot Miranda <[hidden email]>:

Hi Bert,

On Wed, Jan 16, 2019 at 1:24 PM Bert Freudenberg <[hidden email]> wrote:
IMHO the ReleaseBuilder should restart all processes.

And this is essential if there are any significant compiler changes (and there were with the inlining of repeat), because the system should be recompiled and for that to be effective all processes must be restarted.
 

- Bert -

On Sun, Jan 13, 2019 at 12:27 PM Nicolas Cellier <[hidden email]> wrote:
Thanks Max,
good find!
There is certainly a problem in the release procedures.
We have to make sure that the CompiledMethod running are the one installed.
And we should restart the Process for which it's not the case.
How to proceed next?
I think it's a good subject to discuss in Squeak board.

Le dim. 13 janv. 2019 à 10:49, Marcel Taeumel <[hidden email]> a écrit :
Hi, there.

At the moment, "SyntaxError" is not in harmony with the rest of exception handling and debugging. I do have some notes and ideas on how to improve that. Maybe these issues will go away then, too. :-)

I think, we miss a concept to have any kind of interactive tooling for any kind of exception. Right now, there is Debugger and SyntaxError. Etoys has an "Ooops!" dialog. :-) There could be more. Some fancy, some just informative.

Best,
Marcel

Am 13.01.2019 07:59:01 schrieb Max Leske <[hidden email]>:

Hi Nicolas, hi Dave,

I did some more digging and found that the problem is actually present in (probably) every 5.2 image. It can easily be found by opening a fresh image and evaluating "self halt". In the debugger, click on "full stack" and scroll down to the first context (BlockClosure>>newProcess) and click on the entry. This will cause a SyntaxError dialog to open.

Closing both the SyntaxError dialog and the debugger makes the problem go away. The reason for this appears to be that opening the debugger as caused the UI process to be replaced with a new instance (the old instance was the one opened in the debugger). You can see this easily by evaluating "[ self halt ] fork" and clicking on the first stack frame, which will not cause the SyntaxError dialog to open. Alternatively, you could evaluate "Project current spawnNewProcessAndTerminateOld: true".

What I've discovered so far is that the problematic contexts in the UI process (there are multiple) are not the CompiledMethod instances installed in the respective classes. You can verify this by comparing "(BlockClosure>>#newProcess) identityHash" with the hash of the method in the context (select the third last frame, inspect the "thisContext" variable and evaluate "self sender sender method identityHash in that inspector"). After the UI process has been replaced those identity hashes are equal again.
The information in the "old/bad" CompiledMethod obviously points to a bad offset in the changes file.

I also now understand why this only affects the one specific test case: the test accesses the method node for each context in the current process, i.e. the UI process, which includes the bad contexts (access to the method node causes decompilation of the method which causes source access).

Please let me know when you've found a solution and also if I can be of more help.

Cheers,
Max

Hi,

We have an issue in Seaside where a loaded test method holds a bad source pointer. We only noticed because this method accesses the debugger map.

How to reproduce:

clone SmalltalkCI: git clone [hidden email]:hpi-swa/smalltalkCI.git
clone Seaside: git clone [hidden email]:SeasideSt/Seaside.git; git checkout 9cb54a7b14cd254ef318294905c4e8dda8dd9f79
install Seaside in Squeak5.2: <path to SmalltalkCI>/run.sh --headful -s Squeak-5.2 <path to Seaside>/.smalltalk.ston
Run the test WAPharoDebuggerTest>>testNamedTempAt and you'll see a debugger pop up for an UndeclaredVariable. The source lookup is performed in the changes file but in the middle of a chunk of binary (font) data.
I can can only speculate that some of that binary data introduces random chunks which messes with the offsets.

We're adding a workaround for that particular test for now.

Let me know if I can help track down the issue.

Cheers,
Max






--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Wrong method source pointer in Squeak5.2

Nicolas Cellier


Le jeu. 17 janv. 2019 à 08:48, Marcel Taeumel <[hidden email]> a écrit :
Hi, there.

At the moment, processes (should) restart themselves (implicitely) through #cleanUp:. Is there consent that we should make this more explicit in the ReleaseBuilder? If so, when? After condensing changes? After recompiling all?

Best,
Marcel
 
Normally, condenseChanges should just update the CompiledMethod trailer, not fully replace the method, unless I'm wrong?
A mixture of recompileAll followedBy condenseChanges will lead invariably to the bug mentionned by Max.
So without seeing code, my wild guess is that operations take place in this order.

So I would say that retarting process after recompileAll is mandatory.
If you want to be absolutely sure, or if my blind analysis is incorrect, do it after the latest of these two operations.

Nicolas

Am 16.01.2019 23:18:35 schrieb Eliot Miranda <[hidden email]>:

Hi Bert,

On Wed, Jan 16, 2019 at 1:24 PM Bert Freudenberg <[hidden email]> wrote:
IMHO the ReleaseBuilder should restart all processes.

And this is essential if there are any significant compiler changes (and there were with the inlining of repeat), because the system should be recompiled and for that to be effective all processes must be restarted.
 

- Bert -

On Sun, Jan 13, 2019 at 12:27 PM Nicolas Cellier <[hidden email]> wrote:
Thanks Max,
good find!
There is certainly a problem in the release procedures.
We have to make sure that the CompiledMethod running are the one installed.
And we should restart the Process for which it's not the case.
How to proceed next?
I think it's a good subject to discuss in Squeak board.

Le dim. 13 janv. 2019 à 10:49, Marcel Taeumel <[hidden email]> a écrit :
Hi, there.

At the moment, "SyntaxError" is not in harmony with the rest of exception handling and debugging. I do have some notes and ideas on how to improve that. Maybe these issues will go away then, too. :-)

I think, we miss a concept to have any kind of interactive tooling for any kind of exception. Right now, there is Debugger and SyntaxError. Etoys has an "Ooops!" dialog. :-) There could be more. Some fancy, some just informative.

Best,
Marcel

Am 13.01.2019 07:59:01 schrieb Max Leske <[hidden email]>:

Hi Nicolas, hi Dave,

I did some more digging and found that the problem is actually present in (probably) every 5.2 image. It can easily be found by opening a fresh image and evaluating "self halt". In the debugger, click on "full stack" and scroll down to the first context (BlockClosure>>newProcess) and click on the entry. This will cause a SyntaxError dialog to open.

Closing both the SyntaxError dialog and the debugger makes the problem go away. The reason for this appears to be that opening the debugger as caused the UI process to be replaced with a new instance (the old instance was the one opened in the debugger). You can see this easily by evaluating "[ self halt ] fork" and clicking on the first stack frame, which will not cause the SyntaxError dialog to open. Alternatively, you could evaluate "Project current spawnNewProcessAndTerminateOld: true".

What I've discovered so far is that the problematic contexts in the UI process (there are multiple) are not the CompiledMethod instances installed in the respective classes. You can verify this by comparing "(BlockClosure>>#newProcess) identityHash" with the hash of the method in the context (select the third last frame, inspect the "thisContext" variable and evaluate "self sender sender method identityHash in that inspector"). After the UI process has been replaced those identity hashes are equal again.
The information in the "old/bad" CompiledMethod obviously points to a bad offset in the changes file.

I also now understand why this only affects the one specific test case: the test accesses the method node for each context in the current process, i.e. the UI process, which includes the bad contexts (access to the method node causes decompilation of the method which causes source access).

Please let me know when you've found a solution and also if I can be of more help.

Cheers,
Max

Hi,

We have an issue in Seaside where a loaded test method holds a bad source pointer. We only noticed because this method accesses the debugger map.

How to reproduce:

clone SmalltalkCI: git clone [hidden email]:hpi-swa/smalltalkCI.git
clone Seaside: git clone [hidden email]:SeasideSt/Seaside.git; git checkout 9cb54a7b14cd254ef318294905c4e8dda8dd9f79
install Seaside in Squeak5.2: <path to SmalltalkCI>/run.sh --headful -s Squeak-5.2 <path to Seaside>/.smalltalk.ston
Run the test WAPharoDebuggerTest>>testNamedTempAt and you'll see a debugger pop up for an UndeclaredVariable. The source lookup is performed in the changes file but in the middle of a chunk of binary (font) data.
I can can only speculate that some of that binary data introduces random chunks which messes with the offsets.

We're adding a workaround for that particular test for now.

Let me know if I can help track down the issue.

Cheers,
Max






--
_,,,^..^,,,_
best, Eliot



Reply | Threaded
Open this post in threaded view
|

Re: Wrong method source pointer in Squeak5.2

marcel.taeumel
Hi, there.

Please find attached a changeset that fixes the process-restart issue in the release-building "process". :-)

1) long-living processes restarted in #cleanUp

[NEW] the timer interrupt watcher (see Delay)

2) short-living processes restarted in #startUp

[OK] the user interrupt watcher (see EventSensor)
[OK] the event tickler (see EventSensor)
[OK] the WeakArray finalization process (see WeakArray)

[OK] the low space watcher (see ProcessorScheduler)
[UPDATED] the idle process (see ProcessorScheduler)

3) extra, explicit restart in ReleaseBuilder (might be duplicate due to #cleanUp):

[NEW] the timer interrupt watcher (see ReleaseBuilder class >> #prepareProcesses)
[NEW] the UI process (see ReleaseBuilder class >> #saveAndQuit)

@Fabio: For our squeak-app we might want to adapt line 76 in https://github.com/squeak-smalltalk/squeak-app/blob/squeak-trunk/prepare_image.st to call "ReleaseBuilder saveAndQuit" or similar like lines 60 to 63.

Best,
Marcel


Am 17.01.2019 13:40:59 schrieb Nicolas Cellier <[hidden email]>:



Le jeu. 17 janv. 2019 à 08:48, Marcel Taeumel <[hidden email]> a écrit :
Hi, there.

At the moment, processes (should) restart themselves (implicitely) through #cleanUp:. Is there consent that we should make this more explicit in the ReleaseBuilder? If so, when? After condensing changes? After recompiling all?

Best,
Marcel
 
Normally, condenseChanges should just update the CompiledMethod trailer, not fully replace the method, unless I'm wrong?
A mixture of recompileAll followedBy condenseChanges will lead invariably to the bug mentionned by Max.
So without seeing code, my wild guess is that operations take place in this order.

So I would say that retarting process after recompileAll is mandatory.
If you want to be absolutely sure, or if my blind analysis is incorrect, do it after the latest of these two operations.

Nicolas

Am 16.01.2019 23:18:35 schrieb Eliot Miranda <[hidden email]>:

Hi Bert,

On Wed, Jan 16, 2019 at 1:24 PM Bert Freudenberg <[hidden email]> wrote:
IMHO the ReleaseBuilder should restart all processes.

And this is essential if there are any significant compiler changes (and there were with the inlining of repeat), because the system should be recompiled and for that to be effective all processes must be restarted.
 

- Bert -

On Sun, Jan 13, 2019 at 12:27 PM Nicolas Cellier <[hidden email]> wrote:
Thanks Max,
good find!
There is certainly a problem in the release procedures.
We have to make sure that the CompiledMethod running are the one installed.
And we should restart the Process for which it's not the case.
How to proceed next?
I think it's a good subject to discuss in Squeak board.

Le dim. 13 janv. 2019 à 10:49, Marcel Taeumel <[hidden email]> a écrit :
Hi, there.

At the moment, "SyntaxError" is not in harmony with the rest of exception handling and debugging. I do have some notes and ideas on how to improve that. Maybe these issues will go away then, too. :-)

I think, we miss a concept to have any kind of interactive tooling for any kind of exception. Right now, there is Debugger and SyntaxError. Etoys has an "Ooops!" dialog. :-) There could be more. Some fancy, some just informative.

Best,
Marcel

Am 13.01.2019 07:59:01 schrieb Max Leske <[hidden email]>:

Hi Nicolas, hi Dave,

I did some more digging and found that the problem is actually present in (probably) every 5.2 image. It can easily be found by opening a fresh image and evaluating "self halt". In the debugger, click on "full stack" and scroll down to the first context (BlockClosure>>newProcess) and click on the entry. This will cause a SyntaxError dialog to open.

Closing both the SyntaxError dialog and the debugger makes the problem go away. The reason for this appears to be that opening the debugger as caused the UI process to be replaced with a new instance (the old instance was the one opened in the debugger). You can see this easily by evaluating "[ self halt ] fork" and clicking on the first stack frame, which will not cause the SyntaxError dialog to open. Alternatively, you could evaluate "Project current spawnNewProcessAndTerminateOld: true".

What I've discovered so far is that the problematic contexts in the UI process (there are multiple) are not the CompiledMethod instances installed in the respective classes. You can verify this by comparing "(BlockClosure>>#newProcess) identityHash" with the hash of the method in the context (select the third last frame, inspect the "thisContext" variable and evaluate "self sender sender method identityHash in that inspector"). After the UI process has been replaced those identity hashes are equal again.
The information in the "old/bad" CompiledMethod obviously points to a bad offset in the changes file.

I also now understand why this only affects the one specific test case: the test accesses the method node for each context in the current process, i.e. the UI process, which includes the bad contexts (access to the method node causes decompilation of the method which causes source access).

Please let me know when you've found a solution and also if I can be of more help.

Cheers,
Max

Hi,

We have an issue in Seaside where a loaded test method holds a bad source pointer. We only noticed because this method accesses the debugger map.

How to reproduce:

clone SmalltalkCI: git clone [hidden email]:hpi-swa/smalltalkCI.git
clone Seaside: git clone [hidden email]:SeasideSt/Seaside.git; git checkout 9cb54a7b14cd254ef318294905c4e8dda8dd9f79
install Seaside in Squeak5.2: <path to SmalltalkCI>/run.sh --headful -s Squeak-5.2 <path to Seaside>/.smalltalk.ston
Run the test WAPharoDebuggerTest>>testNamedTempAt and you'll see a debugger pop up for an UndeclaredVariable. The source lookup is performed in the changes file but in the middle of a chunk of binary (font) data.
I can can only speculate that some of that binary data introduces random chunks which messes with the offsets.

We're adding a workaround for that particular test for now.

Let me know if I can help track down the issue.

Cheers,
Max






--
_,,,^..^,,,_
best, Eliot




stack-fix.2.cs (4K) Download Attachment