Re: [Moose-dev] Re: Object new foo

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Moose-dev] Re: Object new foo

Vincent Blondeau

Hi,

 

On last Moose image, I debugged the VM and executed “Exception signal”.

I paused the VM and saw that 2 methods are looping together in gcc3x-cointerp.c:

static sqInt findMethodWithPrimitiveFromContextUpToContext(sqInt primitive, sqInt senderContext, sqInt homeContext);

static sqInt findMethodWithPrimitiveFromFPUpToContext(sqInt primitive, char *startFP, sqInt homeContext);

 

The image is looping only when the debugger is launch on Error (not by launching it by the script below).

 

Maybe someone on the Pharo mailing list knows what is happening?

 

Thanks in advance,

 

Cheers,

Vincent

 

De : [hidden email] [mailto:[hidden email]] De la part de Andrei Chis
Envoyé : mardi 18 août 2015 10:53
À : Moose-related development
Objet : [Moose-dev] Re: Object new foo

 

Hi Vincent,

 

You example will also kill the Pharo debugger :)

The issue is that you pass 'Processor activeProcess' which gets terminated when you close the debugger.

When you open the debugger you need to make sure the process

on which it is opened is suspended and can get terminated with no problem.

 

A different way to redo the example would be:

 

context := Context

    sender: nil

    receiver: {1 . 2 . 2}

    method: (OrderedCollection>>#add:)

    arguments: #(10).

process := Process 

                        forContext: context

                        priority: Processor userInterruptPriority.

GTGenericStackDebugger openOn: (DebugSession process: process context: context).

 

There is a basic test for opening the debugger in GTGenericStackDebuggerSmokeTest but more could help.

 

Cheers,

Andrei

 

 

On Mon, Aug 17, 2015 at 11:53 PM, Vincent BLONDEAU <[hidden email]> wrote:

Indeed. Maybe some tests has to be added..

 

But for now, it seems that the debugger is crashing the image… Not just by launching it:

GTGenericStackDebugger openOn: (DebugSession process: Processor activeProcess context:  (Context

                               sender: nil

                               receiver: {1 . 2 . 2}

                               method: (OrderedCollection>>#add: )

                               arguments: #(10)))

 

But when an exception is thrown, its seems that we fall into an infinite loop around the primitive 199. Maybe the context is not well set?

 

Cheers,

Vincent

 

 

 

De : [hidden email] [mailto:[hidden email]] De la part de Alexandre Bergel
Envoyé : lundi 17 août 2015 13:26
À : Moose-related development
Objet : [Moose-dev] Re: Object new foo

 

This is weird that such bug can be introduced and no alarm is raised

 

Alexandre 


Le 17 août 2015 à 08:03, Jan Kurš <[hidden email]> a écrit :

Yep I had this problem (falled back to previous version), I suspected debugger being the reason.

Cheers Jan

 

On Sun, 16 Aug 2015 03:05 Alexandre Bergel <[hidden email]> wrote:

in Moose 6.0 simply freezes.
Anyone else sees this?

Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 

Reply | Threaded
Open this post in threaded view
|

Re: [Moose-dev] Object new foo

abergel
But do we really go into the VM to understand what’s going on?

Alexandre


> On Aug 19, 2015, at 7:22 PM, Vincent BLONDEAU <[hidden email]> wrote:
>
> Hi,
>  
> On last Moose image, I debugged the VM and executed “Exception signal”.
> I paused the VM and saw that 2 methods are looping together in gcc3x-cointerp.c:
> static sqInt findMethodWithPrimitiveFromContextUpToContext(sqInt primitive, sqInt senderContext, sqInt homeContext);
> static sqInt findMethodWithPrimitiveFromFPUpToContext(sqInt primitive, char *startFP, sqInt homeContext);
>  
> The image is looping only when the debugger is launch on Error (not by launching it by the script below).
>  
> Maybe someone on the Pharo mailing list knows what is happening?
>  
> Thanks in advance,
>  
> Cheers,
> Vincent
>  
> De : [hidden email] [mailto:[hidden email]] De la part de Andrei Chis
> Envoyé : mardi 18 août 2015 10:53
> À : Moose-related development
> Objet : [Moose-dev] Re: Object new foo
>  
> Hi Vincent,
>  
> You example will also kill the Pharo debugger :)
> The issue is that you pass 'Processor activeProcess' which gets terminated when you close the debugger.
> When you open the debugger you need to make sure the process
> on which it is opened is suspended and can get terminated with no problem.
>  
> A different way to redo the example would be:
>  
> context := Context
>     sender: nil
>     receiver: {1 . 2 . 2}
>     method: (OrderedCollection>>#add:)
>     arguments: #(10).
> process := Process
>                         forContext: context
>                         priority: Processor userInterruptPriority.
> GTGenericStackDebugger openOn: (DebugSession process: process context: context).
>  
> There is a basic test for opening the debugger in GTGenericStackDebuggerSmokeTest but more could help.
>  
> Cheers,
> Andrei
>  
>  
> On Mon, Aug 17, 2015 at 11:53 PM, Vincent BLONDEAU <[hidden email]> wrote:
>> Indeed. Maybe some tests has to be added..
>>  
>> But for now, it seems that the debugger is crashing the image… Not just by launching it:
>> GTGenericStackDebugger openOn: (DebugSession process: Processor activeProcess context:  (Context
>>                                sender: nil
>>                                receiver: {1 . 2 . 2}
>>                                method: (OrderedCollection>>#add: )
>>                                arguments: #(10)))
>>  
>> But when an exception is thrown, its seems that we fall into an infinite loop around the primitive 199. Maybe the context is not well set?
>>  
>> Cheers,
>> Vincent
>>  
>>  
>>  
>> De : [hidden email] [mailto:[hidden email]] De la part deAlexandre Bergel
>> Envoyé : lundi 17 août 2015 13:26
>> À : Moose-related development
>> Objet : [Moose-dev] Re: Object new foo
>>  
>> This is weird that such bug can be introduced and no alarm is raised
>>  
>> Alexandre
>>
>>
>> Le 17 août 2015 à 08:03, Jan Kurš <[hidden email]> a écrit :
>>
>>> Yep I had this problem (falled back to previous version), I suspected debugger being the reason.
>>>
>>> Cheers Jan
>>>
>>>  
>>> On Sun, 16 Aug 2015 03:05 Alexandre Bergel <[hidden email]> wrote:
>>>> in Moose 6.0 simply freezes.
>>>> Anyone else sees this?
>>>>
>>>> Alexandre
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> Alexandre Bergel  http://www.bergel.eu
>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>  
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.




Reply | Threaded
Open this post in threaded view
|

Re: [Moose-dev] Re: Object new foo

Eliot Miranda-2
In reply to this post by Vincent Blondeau
Hi Vincent,

    does the image lock up when you execute Exception signal?  The two functions you see looping are part of the implementation of primitives 195 & 196, findNextUnwindContextUpTo: (primitiveFindNextUnwindContext) & terminateTo: (primitiveTerminateTo).  So if the image locks up the question is, is what is creating a circular structure of contexts, the VM or the image?  I am willing to take a look at an image that contains the case.  If you can create an image which enters the lop on start-up without my having to do anything I'm happy to take a look.

On Wed, Aug 19, 2015 at 3:22 PM, Vincent BLONDEAU <[hidden email]> wrote:

Hi,

 

On last Moose image, I debugged the VM and executed “Exception signal”.

I paused the VM and saw that 2 methods are looping together in gcc3x-cointerp.c:

static sqInt findMethodWithPrimitiveFromContextUpToContext(sqInt primitive, sqInt senderContext, sqInt homeContext);

static sqInt findMethodWithPrimitiveFromFPUpToContext(sqInt primitive, char *startFP, sqInt homeContext);

 

The image is looping only when the debugger is launch on Error (not by launching it by the script below).

 

Maybe someone on the Pharo mailing list knows what is happening?

 

Thanks in advance,

 

Cheers,

Vincent

 

De : [hidden email] [mailto:[hidden email]] De la part de Andrei Chis
Envoyé : mardi 18 août 2015 10:53
À : Moose-related development
Objet : [Moose-dev] Re: Object new foo

 

Hi Vincent,

 

You example will also kill the Pharo debugger :)

The issue is that you pass 'Processor activeProcess' which gets terminated when you close the debugger.

When you open the debugger you need to make sure the process

on which it is opened is suspended and can get terminated with no problem.

 

A different way to redo the example would be:

 

context := Context

    sender: nil

    receiver: {1 . 2 . 2}

    method: (OrderedCollection>>#add:)

    arguments: #(10).

process := Process 

                        forContext: context

                        priority: Processor userInterruptPriority.

GTGenericStackDebugger openOn: (DebugSession process: process context: context).

 

There is a basic test for opening the debugger in GTGenericStackDebuggerSmokeTest but more could help.

 

Cheers,

Andrei

 

 

On Mon, Aug 17, 2015 at 11:53 PM, Vincent BLONDEAU <[hidden email]> wrote:

Indeed. Maybe some tests has to be added..

 

But for now, it seems that the debugger is crashing the image… Not just by launching it:

GTGenericStackDebugger openOn: (DebugSession process: Processor activeProcess context:  (Context

                               sender: nil

                               receiver: {1 . 2 . 2}

                               method: (OrderedCollection>>#add: )

                               arguments: #(10)))

 

But when an exception is thrown, its seems that we fall into an infinite loop around the primitive 199. Maybe the context is not well set?

 

Cheers,

Vincent

 

 

 

De : [hidden email] [mailto:[hidden email]] De la part de Alexandre Bergel
Envoyé : lundi 17 août 2015 13:26
À : Moose-related development
Objet : [Moose-dev] Re: Object new foo

 

This is weird that such bug can be introduced and no alarm is raised

 

Alexandre 


Le 17 août 2015 à 08:03, Jan Kurš <[hidden email]> a écrit :

Yep I had this problem (falled back to previous version), I suspected debugger being the reason.

Cheers Jan

 

On Sun, 16 Aug 2015 03:05 Alexandre Bergel <[hidden email]> wrote:

in Moose 6.0 simply freezes.
Anyone else sees this?

Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 




--
_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: [Moose-dev] Re: Object new foo

Vincent Blondeau

Hi Eliot,

 

Thanks for your help.

The problem has been resolved!

In fact a class was removed or renamed in Pharo, and the Moose debugger calls it just before the opening.

So it created an infinite loop, because the class wasn’t understood by the system, so it opened another debugger, etc….

 

Do you think something can be made to not break the image and so to break this infinite loop?

A solution may to open either another registered debugger, or the emergency debugger?

 

I can create an image with the problem if needed.

 

Vincent

 

De : Pharo-dev [mailto:[hidden email]] De la part de Eliot Miranda
Envoyé : jeudi 20 août 2015 22:13
À : Pharo Development List
Cc : Moose-related development; Squeak Virtual Machine Development Discussion
Objet : Re: [Pharo-dev] [Moose-dev] Re: Object new foo

 

Hi Vincent,

 

    does the image lock up when you execute Exception signal?  The two functions you see looping are part of the implementation of primitives 195 & 196, findNextUnwindContextUpTo: (primitiveFindNextUnwindContext) & terminateTo: (primitiveTerminateTo).  So if the image locks up the question is, is what is creating a circular structure of contexts, the VM or the image?  I am willing to take a look at an image that contains the case.  If you can create an image which enters the lop on start-up without my having to do anything I'm happy to take a look.

 

On Wed, Aug 19, 2015 at 3:22 PM, Vincent BLONDEAU <[hidden email]> wrote:

Hi,

 

On last Moose image, I debugged the VM and executed “Exception signal”.

I paused the VM and saw that 2 methods are looping together in gcc3x-cointerp.c:

static sqInt findMethodWithPrimitiveFromContextUpToContext(sqInt primitive, sqInt senderContext, sqInt homeContext);

static sqInt findMethodWithPrimitiveFromFPUpToContext(sqInt primitive, char *startFP, sqInt homeContext);

 

The image is looping only when the debugger is launch on Error (not by launching it by the script below).

 

Maybe someone on the Pharo mailing list knows what is happening?

 

Thanks in advance,

 

Cheers,

Vincent

 

De : [hidden email] [mailto:[hidden email]] De la part de Andrei Chis
Envoyé : mardi 18 août 2015 10:53
À : Moose-related development
Objet : [Moose-dev] Re: Object new foo

 

Hi Vincent,

 

You example will also kill the Pharo debugger :)

The issue is that you pass 'Processor activeProcess' which gets terminated when you close the debugger.

When you open the debugger you need to make sure the process

on which it is opened is suspended and can get terminated with no problem.

 

A different way to redo the example would be:

 

context := Context

    sender: nil

    receiver: {1 . 2 . 2}

    method: (OrderedCollection>>#add:)

    arguments: #(10).

process := Process 

                        forContext: context

                        priority: Processor userInterruptPriority.

GTGenericStackDebugger openOn: (DebugSession process: process context: context).

 

There is a basic test for opening the debugger in GTGenericStackDebuggerSmokeTest but more could help.

 

Cheers,

Andrei

 

 

On Mon, Aug 17, 2015 at 11:53 PM, Vincent BLONDEAU <[hidden email]> wrote:

Indeed. Maybe some tests has to be added..

 

But for now, it seems that the debugger is crashing the image… Not just by launching it:

GTGenericStackDebugger openOn: (DebugSession process: Processor activeProcess context:  (Context

                               sender: nil

                               receiver: {1 . 2 . 2}

                               method: (OrderedCollection>>#add: )

                               arguments: #(10)))

 

But when an exception is thrown, its seems that we fall into an infinite loop around the primitive 199. Maybe the context is not well set?

 

Cheers,

Vincent

 

 

 

De : [hidden email] [mailto:[hidden email]] De la part de Alexandre Bergel
Envoyé : lundi 17 août 2015 13:26
À : Moose-related development
Objet : [Moose-dev] Re: Object new foo

 

This is weird that such bug can be introduced and no alarm is raised

 

Alexandre 


Le 17 août 2015 à 08:03, Jan Kurš <[hidden email]> a écrit :

Yep I had this problem (falled back to previous version), I suspected debugger being the reason.

Cheers Jan

 

On Sun, 16 Aug 2015 03:05 Alexandre Bergel <[hidden email]> wrote:

in Moose 6.0 simply freezes.
Anyone else sees this?

Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 



 

--

_,,,^..^,,,_

best, Eliot

Reply | Threaded
Open this post in threaded view
|

Re: [Moose-dev] Re: Object new foo

Eliot Miranda-2
Hi Vincent,

On Sun, Aug 23, 2015 at 9:53 AM, Vincent BLONDEAU <[hidden email]> wrote:

Hi Eliot,

 

Thanks for your help.

The problem has been resolved!

In fact a class was removed or renamed in Pharo, and the Moose debugger calls it just before the opening.

So it created an infinite loop, because the class wasn’t understood by the system, so it opened another debugger, etc….

 

Do you think something can be made to not break the image and so to break this infinite loop?



It may make sense to set a flag early in Debugger opening, and test this flag immediately before it is set to check for recursion.  But the issue is what to do in that case.  One can't open a debugger, because the attempt is failing.  So one can only fall back on some more primitive error handler.  Note that the flag should be specific to the thread of control, which may be difficult if the Debugger runs in a separate process.  One doesn't want to prevent multiple debuggers, only stop recursion within a single error.
 

A solution may to open either another registered debugger, or the emergency debugger?


Yes, the emergency debugger.
 

 

I can create an image with the problem if needed.

 

Vincent

 

De : Pharo-dev [mailto:[hidden email]] De la part de Eliot Miranda
Envoyé : jeudi 20 août 2015 22:13
À : Pharo Development List
Cc : Moose-related development; Squeak Virtual Machine Development Discussion
Objet : Re: [Pharo-dev] [Moose-dev] Re: Object new foo

 

Hi Vincent,

 

    does the image lock up when you execute Exception signal?  The two functions you see looping are part of the implementation of primitives 195 & 196, findNextUnwindContextUpTo: (primitiveFindNextUnwindContext) & terminateTo: (primitiveTerminateTo).  So if the image locks up the question is, is what is creating a circular structure of contexts, the VM or the image?  I am willing to take a look at an image that contains the case.  If you can create an image which enters the lop on start-up without my having to do anything I'm happy to take a look.

 

On Wed, Aug 19, 2015 at 3:22 PM, Vincent BLONDEAU <[hidden email]> wrote:

Hi,

 

On last Moose image, I debugged the VM and executed “Exception signal”.

I paused the VM and saw that 2 methods are looping together in gcc3x-cointerp.c:

static sqInt findMethodWithPrimitiveFromContextUpToContext(sqInt primitive, sqInt senderContext, sqInt homeContext);

static sqInt findMethodWithPrimitiveFromFPUpToContext(sqInt primitive, char *startFP, sqInt homeContext);

 

The image is looping only when the debugger is launch on Error (not by launching it by the script below).

 

Maybe someone on the Pharo mailing list knows what is happening?

 

Thanks in advance,

 

Cheers,

Vincent

 

De : [hidden email] [mailto:[hidden email]] De la part de Andrei Chis
Envoyé : mardi 18 août 2015 10:53
À : Moose-related development
Objet : [Moose-dev] Re: Object new foo

 

Hi Vincent,

 

You example will also kill the Pharo debugger :)

The issue is that you pass 'Processor activeProcess' which gets terminated when you close the debugger.

When you open the debugger you need to make sure the process

on which it is opened is suspended and can get terminated with no problem.

 

A different way to redo the example would be:

 

context := Context

    sender: nil

    receiver: {1 . 2 . 2}

    method: (OrderedCollection>>#add:)

    arguments: #(10).

process := Process 

                        forContext: context

                        priority: Processor userInterruptPriority.

GTGenericStackDebugger openOn: (DebugSession process: process context: context).

 

There is a basic test for opening the debugger in GTGenericStackDebuggerSmokeTest but more could help.

 

Cheers,

Andrei

 

 

On Mon, Aug 17, 2015 at 11:53 PM, Vincent BLONDEAU <[hidden email]> wrote:

Indeed. Maybe some tests has to be added..

 

But for now, it seems that the debugger is crashing the image… Not just by launching it:

GTGenericStackDebugger openOn: (DebugSession process: Processor activeProcess context:  (Context

                               sender: nil

                               receiver: {1 . 2 . 2}

                               method: (OrderedCollection>>#add: )

                               arguments: #(10)))

 

But when an exception is thrown, its seems that we fall into an infinite loop around the primitive 199. Maybe the context is not well set?

 

Cheers,

Vincent

 

 

 

De : [hidden email] [mailto:[hidden email]] De la part de Alexandre Bergel
Envoyé : lundi 17 août 2015 13:26
À : Moose-related development
Objet : [Moose-dev] Re: Object new foo

 

This is weird that such bug can be introduced and no alarm is raised

 

Alexandre 


Le 17 août 2015 à 08:03, Jan Kurš <[hidden email]> a écrit :

Yep I had this problem (falled back to previous version), I suspected debugger being the reason.

Cheers Jan

 

On Sun, 16 Aug 2015 03:05 Alexandre Bergel <[hidden email]> wrote:

in Moose 6.0 simply freezes.
Anyone else sees this?

Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

 



 

--

_,,,^..^,,,_

best, Eliot




--
_,,,^..^,,,_
best, Eliot