Unwind error during termination
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. The steps to reproduce are: open the image, execute 1halt, close debugger ? Best, 2013/10/22 <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
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 ? 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
Le 24/10/2013 16:28, btc@openinworld.com a écrit :
Clément Bera 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 ?
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.
Hi Clément, I really appreciate you having a look but perhaps it would be worthwhile to gather some more use cases before spending too much time on it - unless the challenge is particularly appealing :) . Partly I was checking the wider awareness of this particular error. Even though I've seen it a few times, if no-one else has, then perhaps I should ensure I'm on the latest VM and see if it occurs again. Then might be a better time to attack it.
I see that error sometimes when debugging failed or buggy tests. I'll try to find a way to reproduce. Thierry
cheers -ben
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
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
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
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. 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
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
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.
the stack looks quite strange.. but if you open the debugger on that unwind error and see the #resume: context, evaluating: self isDead yields to true. it is a mystery however, how #resume: end up on the stack, when you just closing the debugger window and terminating the process. it seems like there's a bug somewhere which injects #resume: message send on stack. On 24 October 2013 22:17, Igor Stasenko <siguctua@gmail.com> wrote:
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.
-- Best regards, Igor Stasenko.
ok, it seems i found how to reproduce the situation with following: [ [ 1/0 ] ensure: [ nil foo ] ] on: Error fork: [ :ex | 1halt ] you will get halt, and if you close the debugger , it will throw unwind error. (while instead it should throw DNU) -- Best regards, Igor Stasenko.
Hard to debug this kind of code :( This is reproducible on Squeak wiht on:do:, so on:fork: bizareness apart, this is another flaw in exception handling, along with wrong handler for nested exception (testHandlerFromAction below), unless it's an avatar. Still, I do not see how you get the errorSubscriptBound:... In Squeak that would mean that you sent #handleSignal: to a not isHandlerContext ContextPart... I never saw this, but if Eliot says so... ExceptionTests>>testHandlerFromAction "A test ensuring that nested exceptions work as expected." | result | result := [ [ [self error: 'trigger error'] on: ZeroDivide do: [ :ex | 'inner' ] ] on: Error do: [ :ex | 3 / 0 ] ] on: ZeroDivide do: [ :ex | 'outer' ]. self assert: 'outer' equals: result description: 'Incorrect handler'. 2013/10/24 Igor Stasenko <siguctua@gmail.com>
ok, it seems i found how to reproduce the situation with following:
[ [ 1/0 ] ensure: [ nil foo ] ] on: Error fork: [ :ex | 1halt ]
you will get halt, and if you close the debugger , it will throw unwind error. (while instead it should throw DNU)
-- Best regards, Igor Stasenko.
On 25 October 2013 00:26, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Hard to debug this kind of code :( This is reproducible on Squeak wiht on:do:, so on:fork: bizareness apart, this is another flaw in exception handling, along with wrong handler for nested exception (testHandlerFromAction below), unless it's an avatar.
Still, I do not see how you get the errorSubscriptBound:... In Squeak that would mean that you sent #handleSignal: to a not isHandlerContext ContextPart... I never saw this, but if Eliot says so...
ExceptionTests>>testHandlerFromAction "A test ensuring that nested exceptions work as expected."
| result | result := [ [ [self error: 'trigger error'] on: ZeroDivide do: [ :ex | 'inner' ] ] on: Error do: [ :ex | 3 / 0 ] ] on: ZeroDivide do: [ :ex | 'outer' ]. self assert: 'outer' equals: result description: 'Incorrect handler'.
good find :)
https://pharo.fogbugz.com/f/cases/11996/Wrong-exception-handler-problem
2013/10/24 Igor Stasenko <siguctua@gmail.com>
ok, it seems i found how to reproduce the situation with following:
[ [ 1/0 ] ensure: [ nil foo ] ] on: Error fork: [ :ex | 1halt ]
you will get halt, and if you close the debugger , it will throw unwind error. (while instead it should throw DNU)
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
The author of the test is Andreas Raab, but I'm not sure who found it (excavating mailing list is hard work) 2013/10/25 Igor Stasenko <siguctua@gmail.com>
On 25 October 2013 00:26, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Hard to debug this kind of code :( This is reproducible on Squeak wiht on:do:, so on:fork: bizareness apart, this is another flaw in exception handling, along with wrong handler for nested exception (testHandlerFromAction below), unless it's an avatar.
Still, I do not see how you get the errorSubscriptBound:... In Squeak that would mean that you sent #handleSignal: to a not isHandlerContext ContextPart... I never saw this, but if Eliot says so...
ExceptionTests>>testHandlerFromAction "A test ensuring that nested exceptions work as expected."
| result | result := [ [ [self error: 'trigger error'] on: ZeroDivide do: [ :ex | 'inner' ] ] on: Error do: [ :ex | 3 / 0 ] ] on: ZeroDivide do: [ :ex | 'outer' ]. self assert: 'outer' equals: result description: 'Incorrect handler'.
good find :)
https://pharo.fogbugz.com/f/cases/11996/Wrong-exception-handler-problem
2013/10/24 Igor Stasenko <siguctua@gmail.com>
ok, it seems i found how to reproduce the situation with following:
[ [ 1/0 ] ensure: [ nil foo ] ] on: Error fork: [ :ex | 1halt ]
you will get halt, and if you close the debugger , it will throw unwind error. (while instead it should throw DNU)
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 25 October 2013 01:28, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
The author of the test is Andreas Raab, but I'm not sure who found it (excavating mailing list is hard work)
and this test is missing in pharo, so thanks anyways :)
i can't imagine what can't go wrong is such basic stuff is broken. so we should fix it first, and then see if on:fork: needs some extra handling.
2013/10/25 Igor Stasenko <siguctua@gmail.com>
On 25 October 2013 00:26, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Hard to debug this kind of code :( This is reproducible on Squeak wiht on:do:, so on:fork: bizareness apart, this is another flaw in exception handling, along with wrong handler for nested exception (testHandlerFromAction below), unless it's an avatar.
Still, I do not see how you get the errorSubscriptBound:... In Squeak that would mean that you sent #handleSignal: to a not isHandlerContext ContextPart... I never saw this, but if Eliot says so...
ExceptionTests>>testHandlerFromAction "A test ensuring that nested exceptions work as expected."
| result | result := [ [ [self error: 'trigger error'] on: ZeroDivide do: [ :ex | 'inner' ] ] on: Error do: [ :ex | 3 / 0 ] ] on: ZeroDivide do: [ :ex | 'outer' ]. self assert: 'outer' equals: result description: 'Incorrect handler'.
good find :)
https://pharo.fogbugz.com/f/cases/11996/Wrong-exception-handler-problem
2013/10/24 Igor Stasenko <siguctua@gmail.com>
ok, it seems i found how to reproduce the situation with following:
[ [ 1/0 ] ensure: [ nil foo ] ] on: Error fork: [ :ex | 1halt ]
you will get halt, and if you close the debugger , it will throw unwind error. (while instead it should throw DNU)
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
If I remember correctly andreas wrote the tests. I always like them. Stef
The author of the test is Andreas Raab, but I'm not sure who found it (excavating mailing list is hard work)
2013/10/25 Igor Stasenko <siguctua@gmail.com>
On 25 October 2013 00:26, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote: Hard to debug this kind of code :( This is reproducible on Squeak wiht on:do:, so on:fork: bizareness apart, this is another flaw in exception handling, along with wrong handler for nested exception (testHandlerFromAction below), unless it's an avatar.
Still, I do not see how you get the errorSubscriptBound:... In Squeak that would mean that you sent #handleSignal: to a not isHandlerContext ContextPart... I never saw this, but if Eliot says so...
ExceptionTests>>testHandlerFromAction "A test ensuring that nested exceptions work as expected."
| result | result := [ [ [self error: 'trigger error'] on: ZeroDivide do: [ :ex | 'inner' ] ] on: Error do: [ :ex | 3 / 0 ] ] on: ZeroDivide do: [ :ex | 'outer' ]. self assert: 'outer' equals: result description: 'Incorrect handler'.
good find :)
https://pharo.fogbugz.com/f/cases/11996/Wrong-exception-handler-problem
2013/10/24 Igor Stasenko <siguctua@gmail.com>
ok, it seems i found how to reproduce the situation with following:
[ [ 1/0 ] ensure: [ nil foo ] ] on: Error fork: [ :ex | 1halt ]
you will get halt, and if you close the debugger , it will throw unwind error. (while instead it should throw DNU)
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
(Igor speaking with Clement) Another, tangent. I feel extremely wrong with given piece of code (however it works): [ ^ 2 ] ensure: [ ^ 5 ] my point, that you cannot return from same context twice, and what happens here is really weird. Or even more weird: [ ^ 2 ] ifCurtailed: [ ^ 5 ] or imagine more abstract case: someBlock ifCurtailed: [ ^ 5 ] The someBlock can belong to other context (like the caller context), and if evaluating it leads to non-local return, it must continue execution from the sender context of its home context. But alas, our ifCurtailed block thinks otherwise and intercepts that.. and does own non-local return to possibly alredy unwinded portion of stack.. I feel there's something extremely wrong with that :) We changed the #resume:through: method to catch that: unwindBlock ifCurtailed: [ self error: 'cannot resume execution due to curtailing' ] instead of: unwindBlock value i am, however don't really know what is the least surprising behavior for such situation. 2013/10/25 Stéphane Ducasse <stephane.ducasse@inria.fr>
If I remember correctly andreas wrote the tests. I always like them.
Stef
The author of the test is Andreas Raab, but I'm not sure who found it (excavating mailing list is hard work)
2013/10/25 Igor Stasenko <siguctua@gmail.com>
On 25 October 2013 00:26, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Hard to debug this kind of code :( This is reproducible on Squeak wiht on:do:, so on:fork: bizareness apart, this is another flaw in exception handling, along with wrong handler for nested exception (testHandlerFromAction below), unless it's an avatar.
Still, I do not see how you get the errorSubscriptBound:... In Squeak that would mean that you sent #handleSignal: to a not isHandlerContext ContextPart... I never saw this, but if Eliot says so...
ExceptionTests>>testHandlerFromAction "A test ensuring that nested exceptions work as expected."
| result | result := [ [ [self error: 'trigger error'] on: ZeroDivide do: [ :ex | 'inner' ] ] on: Error do: [ :ex | 3 / 0 ] ] on: ZeroDivide do: [ :ex | 'outer' ]. self assert: 'outer' equals: result description: 'Incorrect handler'.
good find :)
https://pharo.fogbugz.com/f/cases/11996/Wrong-exception-handler-problem
2013/10/24 Igor Stasenko <siguctua@gmail.com>
ok, it seems i found how to reproduce the situation with following:
[ [ 1/0 ] ensure: [ nil foo ] ] on: Error fork: [ :ex | 1halt ]
you will get halt, and if you close the debugger , it will throw unwind error. (while instead it should throw DNU)
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 29 oct. 2013, at 13:22, Clément Bera <bera.clement@gmail.com> wrote:
(Igor speaking with Clement) Another, tangent.
I feel extremely wrong with given piece of code (however it works):
[ ^ 2 ] ensure: [ ^ 5 ]
my point, that you cannot return from same context twice, and what happens here is really weird.
Or even more weird:
[ ^ 2 ] ifCurtailed: [ ^ 5 ]
Debug it -> Into -> Over -> Over (does nothing) -> Over (again) ==> Freeze :)
or imagine more abstract case:
someBlock ifCurtailed: [ ^ 5 ]
The someBlock can belong to other context (like the caller context), and if evaluating it leads to non-local return, it must continue execution from the sender context of its home context. But alas, our ifCurtailed block thinks otherwise and intercepts that.. and does own non-local return to possibly alredy unwinded portion of stack..
I feel there's something extremely wrong with that :)
We changed the #resume:through: method to catch that:
unwindBlock ifCurtailed: [ self error: 'cannot resume execution due to curtailing' ] instead of: unwindBlock value
i am, however don't really know what is the least surprising behavior for such situation.
2013/10/25 Stéphane Ducasse <stephane.ducasse@inria.fr> If I remember correctly andreas wrote the tests. I always like them.
Stef
The author of the test is Andreas Raab, but I'm not sure who found it (excavating mailing list is hard work)
2013/10/25 Igor Stasenko <siguctua@gmail.com>
On 25 October 2013 00:26, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote: Hard to debug this kind of code :( This is reproducible on Squeak wiht on:do:, so on:fork: bizareness apart, this is another flaw in exception handling, along with wrong handler for nested exception (testHandlerFromAction below), unless it's an avatar.
Still, I do not see how you get the errorSubscriptBound:... In Squeak that would mean that you sent #handleSignal: to a not isHandlerContext ContextPart... I never saw this, but if Eliot says so...
ExceptionTests>>testHandlerFromAction "A test ensuring that nested exceptions work as expected."
| result | result := [ [ [self error: 'trigger error'] on: ZeroDivide do: [ :ex | 'inner' ] ] on: Error do: [ :ex | 3 / 0 ] ] on: ZeroDivide do: [ :ex | 'outer' ]. self assert: 'outer' equals: result description: 'Incorrect handler'.
good find :)
https://pharo.fogbugz.com/f/cases/11996/Wrong-exception-handler-problem
2013/10/24 Igor Stasenko <siguctua@gmail.com>
ok, it seems i found how to reproduce the situation with following:
[ [ 1/0 ] ensure: [ nil foo ] ] on: Error fork: [ :ex | 1halt ]
you will get halt, and if you close the debugger , it will throw unwind error. (while instead it should throw DNU)
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On Fri, 25 Oct 2013, Nicolas Cellier wrote:
Hard to debug this kind of code :( This is reproducible on Squeak wiht on:do:, so on:fork: bizareness apart, this is another flaw in exception handling, along with wrong handler for nested exception (testHandlerFromAction below), unless it's an avatar.
Still, I do not see how you get the errorSubscriptBound:... In Squeak that would mean that you sent #handleSignal: to a not isHandlerContext ContextPart... I never saw this, but if Eliot says so...
ExceptionTests>>testHandlerFromAction    "A test ensuring that nested exceptions work as expected."
   | result |    result := [       [          [self error: 'trigger error'] on: ZeroDivide do: [ :ex | 'inner' ]       ] on: Error do: [ :ex | 3 / 0 ]    ] on: ZeroDivide do: [ :ex | 'outer' ].    self assert: 'outer' equals: result description: 'Incorrect handler'.
I had an attempt to fix it, but it's incomplete, and other issues popped up: http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-August/165364.ht... Levente
2013/10/24 Igor Stasenko <siguctua@gmail.com>
ok, it seems i found how to reproduce the situation with following:
[Â [ 1/0 ] ensure: [ nil foo ] ] on: Error fork: [ :ex | 1halt ]
you will get halt, and if you close the debugger , it will throw unwind error. (while instead it should throw DNU)
-- Best regards, Igor Stasenko.
participants (9)
-
btc＠openinworld.com -
Camille Teruel -
Clément Bera -
Eliot Miranda -
Goubier Thierry -
Igor Stasenko -
Levente Uzonyi -
Nicolas Cellier -
Stéphane Ducasse