I doubt that the reason is some bug in VM, i suspecting much simpler explanation: if you look at the bottom of stack, it starts from on:fork: it tries to deliver announcement.. and everything goes well until it gets an exception: PharoLauncher class(Object)>>doesNotUnderstand: #quitOnLaunch the on:fork: then spawns new process forking this part of stack with exception. then right after (i think because you press resume), it tries to resume that exception. The problem is that the context which it tries to resume belonging to different process. The exception is from foreign process, and it simply cannot be resumed, and cannot be unwounded etc because stack is cut by on:fork:. So, to solve the problem is to see why it tries to resume that exception (or maybe you tried to resume it manually?) In short, the wrong is a following: [ 1/0 ] on: Error fork: [ :ex | ex resume ] (strangely enough this code does not raising any errors, perhaps because the signaler context is no longer on stack, and so modifying its state , by running Context>>return: does not causing stack corruption. While in cases, where context is still on parent process stack, it may wreak havoc. On 24 October 2013 21:43, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Thu, Oct 24, 2013 at 11:25 AM, Clément Bera <bera.clement@gmail.com>wrote:
OK I'll wait for another use case or until it happened to me. Like a usecase from a fresh image.
It's just it may be due to the new inspector, new debugger or new compiler. Just wondering.
It's definitely not due to the new code. I see it occasionally in Squeak images without Opal.
2013/10/24 Eliot Miranda <eliot.miranda@gmail.com>
On Thu, Oct 24, 2013 at 12:10 AM, Clément Bera <bera.clement@gmail.com>wrote:
Ok I have the error too.
Strangely enough, the error is triggered because the third BlockClosure>>#on:do: context has 2 temporaries instead of 3.
Igor / Esteban do you have a clue ? Why a context would have less temporaries than expected ? Problem from context creation out of the stack ?
No. It'll be popping too much off the stack. See e.g. ContextPart>>jump.
I will try to find some time to look at this problem. Though it is not an easy one it will take some time to be fixed.
2013/10/24 <btc@openinworld.com>
**
Clément Bera wrote:
Hello,
I'm interested.
Please send me the image in private mail not to overload the mailing list with large attachment. Alternatively, give me a place where I can download it.
http://files.openinworld.com/Pharo/PharoLauncher-Unwind-Error.zip
The steps to reproduce are: open the image, execute 1halt, close debugger ?
There are three debuggers already open. Just close them. The third close generates the error. A confounding factor may be your running this on a different VM. This is mine...
http://files.openinworld.com/Pharo/PharoLauncher-Unwind-Error-VM.zip
Win32 built on Mar 13 2013 18:49:42 Compiler: 4.6.2 VMMaker versionString git://gitorious.org/cogvm/blessed.git Commit: 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By: Esteban Lorenzano <estebanlm@gmail.com> <estebanlm@gmail.com>Jenkins build #14535 NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013
The error still occurs if I try the image on the latest VM, but then again the effect may already be in effect.
btw, Its not directly causing me pain since I can continue in the image, but still thanks for checking it out for general improvements.
cheers -ben
Best,
2013/10/22 <btc@openinworld.com> <btc@openinworld.com>
** For a while now, every now and then when closing a debugger I have been getting an "Unwind error during termination"
I happened to have saved the image moments before it just occurred again. From opening that save error can be reliably triggered in three clicks. I can provide this image if anyone is interested in it.
cheers -ben
-- best, Eliot
-- best, Eliot
-- Best regards, Igor Stasenko.