Smalltalk › Frameworks & Tools › Seaside › Seaside General

VM freezes; how to find the cause?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

24 messages Options

bahman

VM freezes; how to find the cause?

Hi all,

First of all, I'm new to Smalltalk and Seaside so please bear with if
I've got a naive problem.

I'm following Seaside tutorial
(http://www.hpi.uni-potsdam.de/hirschfeld/seaside/tutorial) on Pharo.
At the end of chapter 4
(http://www.hpi.uni-potsdam.de/hirschfeld/seaside/tutorial?_s=AUBiOz9XdOrP9E6O&_k=KG-uwEpv1DslDNOD),
whenever I try to visit the `/todo' URL the whole VM freezes leaving me
with force-close'ing as the only way.

I have two questions:
1. Obviously I'm doing something wrong in the code. Is there any
profiler tool that I can use to trace the problem? With current
situation there's absolutely no way (that I'm aware of) to find out the
bad code.
2. Is it normal that the whole VM becomes unresponsive? I wonder how
to prevent this in a production environment?

TIA,

--
Bahman Movaqar (http://BahmanM.com)
ERP Evaluation, Implementation, Deployment Consultant

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Johan Brichau-2

Re: VM freezes; how to find the cause?

Hi Bahman,

Can you tell us which Smalltalk and which version you are using? Squeak or Pharo or ??

Have you tried putting a 'self halt' in the renderContentOn: method of your todo app?

best regards,
Johan

On 26 May 2013, at 12:00, Bahman Movaqar <[hidden email]> wrote:

> Hi all,
>
> First of all, I'm new to Smalltalk and Seaside so please bear with if
> I've got a naive problem.
>
> I'm following Seaside tutorial
> (http://www.hpi.uni-potsdam.de/hirschfeld/seaside/tutorial) on Pharo.
> At the end of chapter 4
> (http://www.hpi.uni-potsdam.de/hirschfeld/seaside/tutorial?_s=AUBiOz9XdOrP9E6O&_k=KG-uwEpv1DslDNOD),
> whenever I try to visit the `/todo' URL the whole VM freezes leaving me
> with force-close'ing as the only way.
>
> I have two questions:
> 1. Obviously I'm doing something wrong in the code. Is there any
> profiler tool that I can use to trace the problem? With current
> situation there's absolutely no way (that I'm aware of) to find out the
> bad code.
> 2. Is it normal that the whole VM becomes unresponsive? I wonder how
> to prevent this in a production environment?
>
> TIA,
>
> --
> Bahman Movaqar (http://BahmanM.com)
> ERP Evaluation, Implementation, Deployment Consultant
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

bahman

Re: VM freezes; how to find the cause?

Hi Johan,

As I said, I'm using Pharo (2.0). And yes, I just tried putting `self
halt' and the beginning of the `renderContentOn:' and the result was the
same.

This means that something is going wrong in the `initialize' method, right?

Thanks,

--
Bahman Movaqar (http://BahmanM.com)
ERP Evaluation, Implementation, Deployment Consultant

On 2013-05-26 14:55, Johan Brichau wrote:

> Hi Bahman,
>
> Can you tell us which Smalltalk and which version you are using? Squeak or Pharo or ??
>
> Have you tried putting a 'self halt' in the renderContentOn: method of your todo app?
>
> best regards,
> Johan
>
> On 26 May 2013, at 12:00, Bahman Movaqar <[hidden email]> wrote:
>
>> Hi all,
>>
>> First of all, I'm new to Smalltalk and Seaside so please bear with if
>> I've got a naive problem.
>>
>> I'm following Seaside tutorial
>> (http://www.hpi.uni-potsdam.de/hirschfeld/seaside/tutorial) on Pharo.
>> At the end of chapter 4
>> (http://www.hpi.uni-potsdam.de/hirschfeld/seaside/tutorial?_s=AUBiOz9XdOrP9E6O&_k=KG-uwEpv1DslDNOD),
>> whenever I try to visit the `/todo' URL the whole VM freezes leaving me
>> with force-close'ing as the only way.
>>
>> I have two questions:
>> 1. Obviously I'm doing something wrong in the code. Is there any
>> profiler tool that I can use to trace the problem? With current
>> situation there's absolutely no way (that I'm aware of) to find out the
>> bad code.
>> 2. Is it normal that the whole VM becomes unresponsive? I wonder how
>> to prevent this in a production environment?
>>
>> TIA,
>>
>> --
>> Bahman Movaqar (http://BahmanM.com)
>> ERP Evaluation, Implementation, Deployment Consultant
>>
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Johan Brichau-2

Re: VM freezes; how to find the cause?

On 26 May 2013, at 12:30, Bahman Movaqar <[hidden email]> wrote:

> As I said, I'm using Pharo (2.0).

sorry, missed that part.

> This means that something is going wrong in the `initialize' method, right?

Possibly. What is the code of your initialize method?
The most common cause would be an infinite loop by doing a 'self initialize' instead of a super initialize inside your initialize method.

Johan_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

bahman

Re: VM freezes; how to find the cause?

Apparently `initialize' is done correctly because when I put `self
halt.' at the bottom of `initialize' the VM actually halts there. But
after pushing the "proceed" button, it freezes again.

<code>

StRootComponent >>#initialize
super initialize.
self
menuComponent: self initializeMenuComponent;
listComponent: self initializeListComponent.

StRootComponent >>#initializeListComponent
self listComponent: StListComponent new.
self listComponent
sortBlock: [ :items | items sortBy: [ :a :b | a deadline >#initializeMenuComponent
self
menuComponent:
(StMenuComponent new
addEntry: 'All' withAction: [ self showAllTasks ];
addEntry: 'Completed' withAction: [ self
showCompletedTasks ];
addEntry: 'Pending' withAction: [ self showPendingTasks ];
addEntry: 'Missed' withAction: [ self showMissedTasks ];
yourself)

StRootComponent >>#testTasks
^ OrderedCollection
with:
(StTask new
deadline: Date yesterday;
completed: false;
taskName: 'Missed task')
with:
(StTask new
deadline: Date tomorrow;
completed: false;
taskName: 'Pending task')
with:
(StTask new
deadline: Date tomorrow;
completed: true;
taskName: 'Already completed task')
</code>

TIA,

--
Bahman Movaqar (http://BahmanM.com)
ERP Evaluation, Implementation, Deployment Consultant

On 2013-05-26 15:04, Johan Brichau wrote:

> On 26 May 2013, at 12:30, Bahman Movaqar <[hidden email]> wrote:
>
>> As I said, I'm using Pharo (2.0).
> sorry, missed that part.
>
>> This means that something is going wrong in the `initialize' method, right?
> Possibly. What is the code of your initialize method?
> The most common cause would be an infinite loop by doing a 'self initialize' instead of a super initialize inside your initialize method.
>
> Johan_______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Max Leske

Re: VM freezes; how to find the cause?

When the image (VM as you say) stops responding, could you try hitting cmd + . (that's on Mac, try alt + . too)? That should interrupt the running process.

Max

On 26.05.2013, at 13:48, Bahman Movaqar <[hidden email]> wrote:

> Apparently `initialize' is done correctly because when I put `self
> halt.' at the bottom of `initialize' the VM actually halts there. But
> after pushing the "proceed" button, it freezes again.
>
> <code>
>
> StRootComponent >>#initialize
> super initialize.
> self
> menuComponent: self initializeMenuComponent;
> listComponent: self initializeListComponent.
>
>
> StRootComponent >>#initializeListComponent
> self listComponent: StListComponent new.
> self listComponent
> sortBlock: [ :items | items sortBy: [ :a :b | a deadline deadline ] ];
> renderItemBlock: [ :task :html | self renderTask: task asRowOn:
> html ].
> self showPendingTasks.
> self listComponent items: self testTasks.
>
>
> StRootComponent >>#initializeMenuComponent
> self
> menuComponent:
> (StMenuComponent new
> addEntry: 'All' withAction: [ self showAllTasks ];
> addEntry: 'Completed' withAction: [ self
> showCompletedTasks ];
> addEntry: 'Pending' withAction: [ self showPendingTasks ];
> addEntry: 'Missed' withAction: [ self showMissedTasks ];
> yourself)
>
>
> StRootComponent >>#testTasks
> ^ OrderedCollection
> with:
> (StTask new
> deadline: Date yesterday;
> completed: false;
> taskName: 'Missed task')
> with:
> (StTask new
> deadline: Date tomorrow;
> completed: false;
> taskName: 'Pending task')
> with:
> (StTask new
> deadline: Date tomorrow;
> completed: true;
> taskName: 'Already completed task')
> </code>
>
> TIA,
>
> --
> Bahman Movaqar (http://BahmanM.com)
> ERP Evaluation, Implementation, Deployment Consultant
>
> On 2013-05-26 15:04, Johan Brichau wrote:
>> On 26 May 2013, at 12:30, Bahman Movaqar <[hidden email]> wrote:
>>
>>> As I said, I'm using Pharo (2.0).
>> sorry, missed that part.
>>
>>> This means that something is going wrong in the `initialize' method, right?
>> Possibly. What is the code of your initialize method?
>> The most common cause would be an infinite loop by doing a 'self initialize' instead of a super initialize inside your initialize method.
>>
>> Johan_______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

bahman

Re: VM freezes; how to find the cause?

Yay! Thanks Max. At least now I can do something without closing Pharo :-)

Not sure how could I dump the stacktrace into a file but I've attached
the screenshot.

--
Bahman Movaqar (http://BahmanM.com)
ERP Evaluation, Implementation, Deployment Consultant

On 2013-05-26 16:23, Max Leske wrote:

> When the image (VM as you say) stops responding, could you try hitting cmd + . (that's on Mac, try alt + . too)? That should interrupt the running process.
>
> Max
>
>
> On 26.05.2013, at 13:48, Bahman Movaqar <[hidden email]> wrote:
>
>> Apparently `initialize' is done correctly because when I put `self
>> halt.' at the bottom of `initialize' the VM actually halts there. But
>> after pushing the "proceed" button, it freezes again.
>>
>> <code>
>>
>> StRootComponent >>#initialize
>> super initialize.
>> self
>> menuComponent: self initializeMenuComponent;
>> listComponent: self initializeListComponent.
>>
>>
>> StRootComponent >>#initializeListComponent
>> self listComponent: StListComponent new.
>> self listComponent
>> sortBlock: [ :items | items sortBy: [ :a :b | a deadline > deadline ] ];
>> renderItemBlock: [ :task :html | self renderTask: task asRowOn:
>> html ].
>> self showPendingTasks.
>> self listComponent items: self testTasks.
>>
>>
>> StRootComponent >>#initializeMenuComponent
>> self
>> menuComponent:
>> (StMenuComponent new
>> addEntry: 'All' withAction: [ self showAllTasks ];
>> addEntry: 'Completed' withAction: [ self
>> showCompletedTasks ];
>> addEntry: 'Pending' withAction: [ self showPendingTasks ];
>> addEntry: 'Missed' withAction: [ self showMissedTasks ];
>> yourself)
>>
>>
>> StRootComponent >>#testTasks
>> ^ OrderedCollection
>> with:
>> (StTask new
>> deadline: Date yesterday;
>> completed: false;
>> taskName: 'Missed task')
>> with:
>> (StTask new
>> deadline: Date tomorrow;
>> completed: false;
>> taskName: 'Pending task')
>> with:
>> (StTask new
>> deadline: Date tomorrow;
>> completed: true;
>> taskName: 'Already completed task')
>> </code>
>>
>> TIA,
>>
>> --
>> Bahman Movaqar (http://BahmanM.com)
>> ERP Evaluation, Implementation, Deployment Consultant
>>
>> On 2013-05-26 15:04, Johan Brichau wrote:
>>> On 26 May 2013, at 12:30, Bahman Movaqar <[hidden email]> wrote:
>>>
>>>> As I said, I'm using Pharo (2.0).
>>> sorry, missed that part.
>>>
>>>> This means that something is going wrong in the `initialize' method, right?
>>> Possibly. What is the code of your initialize method?
>>> The most common cause would be an infinite loop by doing a 'self initialize' instead of a super initialize inside your initialize method.
>>>
>>> Johan_______________________________________________
>>> seaside mailing list
>>> [hidden email]
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Pharo-Stacktrace.png (228K) Download Attachment

xx397

Re: VM freezes; how to find the cause?

In reply to this post by bahman

#initalizeMenuComponent and #initializeListComponent are not returning
anything (and will therefore return self, the StRootComponent) This
means you will have an infinite loop as StRootComponent contains itself

One way to fix it would be to change your initialize method as follows
as you are already setting the menuComponent and listComponent variables
in their own initialize methods:

StRootComponent >>#initialize
super initialize.
self
initializeMenuComponent;
initializeListComponent.

> Apparently `initialize' is done correctly because when I put `self
> halt.' at the bottom of `initialize' the VM actually halts there. But
> after pushing the "proceed" button, it freezes again.
>
> <code>
>
> StRootComponent >>#initialize
> super initialize.
> self
> menuComponent: self initializeMenuComponent;
> listComponent: self initializeListComponent.
>
>
> StRootComponent >>#initializeListComponent
> self listComponent: StListComponent new.
> self listComponent
> sortBlock: [ :items | items sortBy: [ :a :b | a deadline deadline ] ];
> renderItemBlock: [ :task :html | self renderTask: task asRowOn:
> html ].
> self showPendingTasks.
> self listComponent items: self testTasks.
>
>
> StRootComponent >>#initializeMenuComponent
> self
> menuComponent:
> (StMenuComponent new
> addEntry: 'All' withAction: [ self showAllTasks ];
> addEntry: 'Completed' withAction: [ self
> showCompletedTasks ];
> addEntry: 'Pending' withAction: [ self showPendingTasks ];
> addEntry: 'Missed' withAction: [ self showMissedTasks ];
> yourself)
>
>
> StRootComponent >>#testTasks
> ^ OrderedCollection
> with:
> (StTask new
> deadline: Date yesterday;
> completed: false;
> taskName: 'Missed task')
> with:
> (StTask new
> deadline: Date tomorrow;
> completed: false;
> taskName: 'Pending task')
> with:
> (StTask new
> deadline: Date tomorrow;
> completed: true;
> taskName: 'Already completed task')
> </code>
>
> TIA,
>
> --
> Bahman Movaqar (http://BahmanM.com)
> ERP Evaluation, Implementation, Deployment Consultant
>
> On 2013-05-26 15:04, Johan Brichau wrote:
>> On 26 May 2013, at 12:30, Bahman Movaqar <[hidden email]> wrote:
>>
>>> As I said, I'm using Pharo (2.0).
>> sorry, missed that part.
>>
>>> This means that something is going wrong in the `initialize' method, right?
>> Possibly. What is the code of your initialize method?
>> The most common cause would be an infinite loop by doing a 'self initialize' instead of a super initialize inside your initialize method.
>>
>> Johan_______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

bahman

Re: VM freezes; how to find the cause?

On 2013-05-26 16:40, Chris wrote:
> #initalizeMenuComponent and #initializeListComponent are not returning
> anything (and will therefore return self, the StRootComponent) This
> means you will have an infinite loop as StRootComponent contains itself

Oh. I was under the impression that a value is returned only when `^'
operator is used.

> One way to fix it would be to change your initialize method as follows
> as you are already setting the menuComponent and listComponent variables
> in their own initialize methods:
>
> StRootComponent >>#initialize
> super initialize.
> self
> initializeMenuComponent;
> initializeListComponent.

Thanks for the suggestion but it doesn't solve the freeze problem.

>> Apparently `initialize' is done correctly because when I put `self
>> halt.' at the bottom of `initialize' the VM actually halts there. But
>> after pushing the "proceed" button, it freezes again.
>>
>> <code>
>>
>> StRootComponent >>#initialize
>> super initialize.
>> self
>> menuComponent: self initializeMenuComponent;
>> listComponent: self initializeListComponent.
>>
>>
>> StRootComponent >>#initializeListComponent
>> self listComponent: StListComponent new.
>> self listComponent
>> sortBlock: [ :items | items sortBy: [ :a :b | a deadline > deadline ] ];
>> renderItemBlock: [ :task :html | self renderTask: task asRowOn:
>> html ].
>> self showPendingTasks.
>> self listComponent items: self testTasks.
>>
>>
>> StRootComponent >>#initializeMenuComponent
>> self
>> menuComponent:
>> (StMenuComponent new
>> addEntry: 'All' withAction: [ self showAllTasks ];
>> addEntry: 'Completed' withAction: [ self
>> showCompletedTasks ];
>> addEntry: 'Pending' withAction: [ self
>> showPendingTasks ];
>> addEntry: 'Missed' withAction: [ self showMissedTasks ];
>> yourself)
>>
>>
>> StRootComponent >>#testTasks
>> ^ OrderedCollection
>> with:
>> (StTask new
>> deadline: Date yesterday;
>> completed: false;
>> taskName: 'Missed task')
>> with:
>> (StTask new
>> deadline: Date tomorrow;
>> completed: false;
>> taskName: 'Pending task')
>> with:
>> (StTask new
>> deadline: Date tomorrow;
>> completed: true;
>> taskName: 'Already completed task')
>> </code>
>>
>> On 2013-05-26 15:04, Johan Brichau wrote:
>>> On 26 May 2013, at 12:30, Bahman Movaqar <[hidden email]> wrote:
>>>
>>>> As I said, I'm using Pharo (2.0).
>>> sorry, missed that part.
>>>
>>>> This means that something is going wrong in the `initialize' method,
>>>> right?
>>> Possibly. What is the code of your initialize method?
>>> The most common cause would be an infinite loop by doing a 'self
>>> initialize' instead of a super initialize inside your initialize method.

--
Bahman Movaqar (http://BahmanM.com)
ERP Evaluation, Implementation, Deployment Consultant
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

bahman

Re: VM freezes; how to find the cause?

In reply to this post by bahman

On 2013-05-26 14:30, Bahman Movaqar wrote:

I have attached the full stack trace of the frozen VM (Oops! Image :-)
). Please note that `StRootComponent' is the component I've coded and
most probably the root of all evil.

--
Bahman Movaqar (http://BahmanM.com)
ERP Evaluation, Implementation, Deployment Consultant

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

pharo-stacktrace.txt (2K) Download Attachment

bahman

Re: VM freezes; how to find the cause?

On 2013-05-27 08:00, Bahman Movaqar wrote:

> On 2013-05-26 14:30, Bahman Movaqar wrote:
>> Hi all,
>>
>> First of all, I'm new to Smalltalk and Seaside so please bear with if
>> I've got a naive problem.
>>
>> I'm following Seaside tutorial
>> (http://www.hpi.uni-potsdam.de/hirschfeld/seaside/tutorial) on Pharo.
>> At the end of chapter 4
>> (http://www.hpi.uni-potsdam.de/hirschfeld/seaside/tutorial?_s=AUBiOz9XdOrP9E6O&_k=KG-uwEpv1DslDNOD),
>> whenever I try to visit the `/todo' URL the whole VM freezes leaving me
>> with force-close'ing as the only way.
>>
>> I have two questions:
>> 1. Obviously I'm doing something wrong in the code. Is there any
>> profiler tool that I can use to trace the problem? With current
>> situation there's absolutely no way (that I'm aware of) to find out the
>> bad code.
>> 2. Is it normal that the whole VM becomes unresponsive? I wonder how
>> to prevent this in a production environment?
>
> I have attached the full stack trace of the frozen VM (Oops! Image :-)
> ). Please note that `StRootComponent' is the component I've coded and
> most probably the root of all evil.

Finally! At last the page is showing up. I'm not sure how but the only
things I did to code were Chris' suggestion and some cleanup.

And, as far as I could understand, `OrderedCollection' doesn't provide
`sortBy:' (which is used in the tutorial) anymore as it is `sort:' now.

Thank you all for your help. Much appreciated.

Now the only thing that is occupying my mind is the whole image freeze.
It's not good at all for a production environment where one website
should *not* bring down 10 other websites because it can make the image
freeze.

Is there any way to prevent that? Or at least limit the freeze to a
thread or a process instead of whole image.

TIA,

--
Bahman Movaqar (http://BahmanM.com)
ERP Evaluation, Implementation, Deployment Consultant
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Tobias Pape

Re: VM freezes; how to find the cause?

Hi

Am 27.05.2013 um 06:13 schrieb Bahman Movaqar <[hidden email]>:

> On 2013-05-27 08:00, Bahman Movaqar wrote:
>> On 2013-05-26 14:30, Bahman Movaqar wrote:
>>> Hi all,
>>>
>>> First of all, I'm new to Smalltalk and Seaside so please bear with if
>>> I've got a naive problem.
>>>
>>> I'm following Seaside tutorial
>>> (http://www.hpi.uni-potsdam.de/hirschfeld/seaside/tutorial) on Pharo.
>>> At the end of chapter 4
>>> (http://www.hpi.uni-potsdam.de/hirschfeld/seaside/tutorial?_s=AUBiOz9XdOrP9E6O&_k=KG-uwEpv1DslDNOD),
>>> whenever I try to visit the `/todo' URL the whole VM freezes leaving me
>>> with force-close'ing as the only way.
>>>
>>> I have two questions:
>>> 1. Obviously I'm doing something wrong in the code. Is there any
>>> profiler tool that I can use to trace the problem? With current
>>> situation there's absolutely no way (that I'm aware of) to find out the
>>> bad code.
>>> 2. Is it normal that the whole VM becomes unresponsive? I wonder how
>>> to prevent this in a production environment?
>>
>> I have attached the full stack trace of the frozen VM (Oops! Image :-)
>> ). Please note that `StRootComponent' is the component I've coded and
>> most probably the root of all evil.
>
> Finally! At last the page is showing up. I'm not sure how but the only
> things I did to code were Chris' suggestion and some cleanup.
>
> And, as far as I could understand, `OrderedCollection' doesn't provide
> `sortBy:' (which is used in the tutorial) anymore as it is `sort:' now.

Please note that the tutorial is written with Squeak as the platform in mind.
Hence, when you try it on Pharo, in one or two places you will need to adapt
the code :)

>
> Thank you all for your help. Much appreciated.
>
> Now the only thing that is occupying my mind is the whole image freeze.
> It's not good at all for a production environment where one website
> should *not* bring down 10 other websites because it can make the image
> freeze.
>
> Is there any way to prevent that? Or at least limit the freeze to a
> thread or a process instead of whole image.

As Chris (?) figured out, your freeze was because of an infinite recursion,
and those things are very hard to catch; it is actually no freeze but continuing
execution. It is near impossible to catch that with the current architecture
of either Squeak or Pharo.

Best
-Tobias

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Bob Arning-2

Re: VM freezes; how to find the cause?

It may not be *that* hard. Start a high-priority process that frequently checks the state of Squeak memory and stops the offending process(es) if things are looking dire.

Cheers,
Bob

On 5/27/13 8:56 AM, Tobias Pape wrote:

As Chris (?) figured out, your freeze was because of an infinite recursion,
and those things are very hard to catch; it is actually no freeze but continuing
execution. It is near impossible to catch that with the current architecture
of either Squeak or Pharo.

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

bahman

Re: VM freezes; how to find the cause?

On 2013-05-27 18:30, Bob Arning wrote:
> It may not be *that* hard. Start a high-priority process that frequently
> checks the state of Squeak memory and stops the offending process(es) if
> things are looking dire.

@Bob: You mean an OS-level process or Squeak-level?

> Cheers,
> Bob
>
> On 5/27/13 8:56 AM, Tobias Pape wrote:
>> As Chris (?) figured out, your freeze was because of an infinite recursion,
>> and those things are very hard to catch; it is actually no freeze but continuing
>> execution. It is near impossible to catch that with the current architecture
>> of either Squeak or Pharo.

@Tobias: That's not good. Imagine an image serving multiple sites. If
one site gets blocked, all other will be unresponsive as well :-(

--
Bahman Movaqar (http://BahmanM.com)
ERP Evaluation, Implementation, Deployment Consultant
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Bob Arning-2

Re: VM freezes; how to find the cause?

Squeak, definitely. I know next to nothing about the OS level. ;-)

Cheers,
Bob

On 5/27/13 10:03 AM, Bahman Movaqar wrote:

On 2013-05-27 18:30, Bob Arning wrote:

> It may not be *that* hard. Start a high-priority process that frequently
> checks the state of Squeak memory and stops the offending process(es) if
> things are looking dire.

@Bob: You mean an OS-level process or Squeak-level?

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

bahman

Re: VM freezes; how to find the cause?

On 2013-05-27 18:38, Bob Arning wrote:
> Squeak, definitely. I know next to nothing about the OS level. ;-)

Well, if that's possible then something can be thought out. Thanks for
the hint.

>
> On 5/27/13 10:03 AM, Bahman Movaqar wrote:
>> On 2013-05-27 18:30, Bob Arning wrote:
>>> > It may not be *that* hard. Start a high-priority process that frequently
>>> > checks the state of Squeak memory and stops the offending process(es) if
>>> > things are looking dire.
>> @Bob: You mean an OS-level process or Squeak-level?

--
Bahman Movaqar (http://BahmanM.com)
ERP Evaluation, Implementation, Deployment Consultant
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

mozillanerd

Re: VM freezes; how to find the cause?

Bahman Movaqar <Bahman <at> BahmanM.com> writes:

>
> On 2013-05-27 18:38, Bob Arning wrote:
> > Squeak, definitely. I know next to nothing about the OS level.
>
> Well, if that's possible then something can be thought out. Thanks for
> the hint.
>
> >
> > On 5/27/13 10:03 AM, Bahman Movaqar wrote:
> >> On 2013-05-27 18:30, Bob Arning wrote:
> >>> > It may not be *that* hard. Start a high-priority process that frequently
> >>> > checks the state of Squeak memory and stops the offending process(es) if
> >>> > things are looking dire.
> >> <at> Bob: You mean an OS-level process or Squeak-level?
>

As you now know, it is very simple to inadvertently cause your code to
freeze. I have managed to get my code to freeze in various ways including
recursion caused by initialize.AND, test before you deploy in a production
environment.

The VM is correctly doing what you tell it to do.

I don't know whether VisualWorks oe Object Studio by Cincom has a code
'freeze' detector, but it is worth a try as it is a commercial environment
(they offer a free vorsion); you can try your bad initialize there.
You may wish to consult http://www.smalltalk.org/versions for other versions.
Good luck

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

jtuchel

Re: VM freezes; how to find the cause?

Am 27.05.13 19:59, schrieb intrader:
> I don't know whether VisualWorks oe Object Studio by Cincom has a code
> 'freeze' detector, but it is worth a try as it is a commercial
> environment (they offer a free vorsion); you can try your bad
> initialize there. You may wish to consult
> http://www.smalltalk.org/versions for other versions. Good luck

As far as I know, there is a keyboard shortcut (was it ctrl-SysRq?) in
VisualWorks to stop a runnig process and jump right into a debugger.
Newer versions of ObjectStudio run in a VisualWorks VM, so I'd guess the
same keystroke works as well.
In VAST (the environment I know best), you have a little extra button on
the screen that does the same. Since that button is not controlled by
Smalltalk code but by the VM, it does work in 99.9% of the cases (Of
course you use another vm executable for your deployment).
Instantiations also offers a free evaluation license that you can use to
experiment.

In most Smalltalks I've used, you can use the debugger to break right
into any running smalltalk process that you'd like to take a closer look
at... It can be challenging to open a debugger on a background process
that's gone wild, because there can be multiple processes running and
the process names are not always helping you much.

Most of the time, you end up with a StackOverflow exception if you run
into a never-ending recursion, so you usually end up in the debugger
anyways and the challenge is to dive down deep enough into the stack
trace to find where the evil started ;-)

Joachim
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

mozillanerd

Re: VM freezes; how to find the cause?

Joachim Tuchel <jtuchel <at> objektfabrik.de> writes:

>
>...

Excellent info about VidualWorks, thanks

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

bahman

Re: VM freezes; how to find the cause?

In reply to this post by mozillanerd

On 2013-05-27 22:29, intrader wrote:
> As you now know, it is very simple to inadvertently cause your code to
> freeze. I have managed to get my code to freeze in various ways including
> recursion caused by initialize.AND, test before you deploy in a production
> environment.
>
> The VM is correctly doing what you tell it to do.

That's right.

My only question is that, should a single bad process freeze the whole
image?

A process can go CPU-wild not only during initialisation but also by I/O
block/deadlock, e.g. when accessing the database. I know, it is not
usual or something that happens on a daily basis.

I've had this on JVM: running multiple applications on a web server.
Out there if the freeze happened at web server level, well, all
applications were down and out of reach. However if the freeze happened
in application (my code) level, the CPU usage would increase -sometimes
to 100%- but the other web applications would remain accessible though slow.

I'm wondering about a way to achieve the same behaviour on Smalltalk.

--
Bahman Movaqar (http://BahmanM.com)
ERP Evaluation, Implementation, Deployment Consultant
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside