[squeak-dev] Wrong method source pointer in Squeak5.2

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Jan 16 18:40:21 UTC 2019


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

Le dim. 13 janv. 2019 à 21:27, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> 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 <marcel.taeumel at hpi.de> 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 <maxleske at gmail.com>:
>>
>> 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 git at github.com:hpi-swa/smalltalkCI.git
>> clone Seaside: git clone git at github.com: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
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190116/e4a02bd8/attachment.html>


More information about the Squeak-dev mailing list