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, squeak-dev-request at lists.squeakfoundation.org 
wrote:

> 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