<div dir="ltr"><div>Thanks Max,</div><div>good find!</div><div>There is certainly a problem in the release procedures.</div><div>We have to make sure that the CompiledMethod running are the one installed.</div><div>And we should restart the Process for which it's not the case.</div><div>How to proceed next?<br></div><div>I think it's a good subject to discuss in Squeak board.<br></div></div><br><div class="gmail_quote"><div dir="ltr">Le dim. 13 janv. 2019 à 10:49, Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de">marcel.taeumel@hpi.de</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-m_8416282942978305758__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0)">
                                        
                                        
                                            
                                        
                                        
                                        Hi, there.<div><br></div><div>At the moment, "<span style="font-family:sans-serif;font-size:13px;line-height:19.5px">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. :-)</span></div><div><span style="font-family:sans-serif;font-size:13px;line-height:19.5px"><br></span></div><div><span style="font-family:sans-serif;font-size:13px;line-height:19.5px">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.</span></div><div><span style="font-family:sans-serif;font-size:13px;line-height:19.5px"><br></span></div><div><span style="font-family:sans-serif;font-size:13px;line-height:19.5px">Best,</span></div><div><span style="font-family:sans-serif;font-size:13px;line-height:19.5px">Marcel</span></div><div class="gmail-m_8416282942978305758mb_sig"></div>
                                        
                                        <blockquote class="gmail-m_8416282942978305758history_container" type="cite" style="border-left-style:solid;border-width:1px;margin-top:20px;margin-left:0px;padding-left:10px;min-width:500px">
                        <p style="color:rgb(170,170,170);margin-top:10px">Am 13.01.2019 07:59:01 schrieb Max Leske <<a href="mailto:maxleske@gmail.com" target="_blank">maxleske@gmail.com</a>>:</p><div style="font-family:Arial,Helvetica,sans-serif">
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">Hi Nicolas, hi Dave,</p>

<p dir="auto">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.</p>

<p dir="auto">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".</p>

<p dir="auto">What I've discovered so far is that the problematic contexts in the UI process (there are multiple) are <em>not</em> 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.<br>
The information in the "old/bad" CompiledMethod obviously points to a bad offset in the changes file.</p>

<p dir="auto">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).</p>

<p dir="auto">Please let me know when you've found a solution and also if I can be of more help.</p>

<p dir="auto">Cheers,<br>
Max</p>

<blockquote style="border-left:2px solid rgb(119,119,119);color:rgb(119,119,119);margin:0px 0px 5px;padding-left:5px;min-width:500px">
<p dir="auto">Hi,</p>

<p dir="auto">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.</p>

<p dir="auto">How to reproduce:</p>

<p dir="auto">clone SmalltalkCI: git clone <a href="mailto:git@github.com" style="color:rgb(119,119,119)" target="_blank">git@github.com</a>:hpi-swa/smalltalkCI.git<br>
clone Seaside: git clone <a href="mailto:git@github.com" style="color:rgb(119,119,119)" target="_blank">git@github.com</a>:SeasideSt/Seaside.git; git checkout 9cb54a7b14cd254ef318294905c4e8dda8dd9f79<br>
install Seaside in Squeak5.2: <path to SmalltalkCI>/run.sh --headful -s Squeak-5.2 <path to Seaside>/.smalltalk.ston<br>
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.<br>
I can can only speculate that some of that binary data introduces random chunks which messes with the offsets.</p>

<p dir="auto">We're adding a workaround for that particular test for now.</p>

<p dir="auto">Let me know if I can help track down the issue.</p>

<p dir="auto">Cheers,<br>
Max</p>
</blockquote>
</div>
</div>
</div></blockquote></div><br>
</blockquote></div>