startup errors
Locked
 
|
While working on Coral we encountered a rather annoying behavior of pharo images when starting up.
We wanted to check if we can debug the CoralScriptLoader, but of corse since this happens at image startup time this is not a good idea… HOWEVER we were no longer able to run the image as it immediately crashes during the startup. Now I wonder if it would make sense to add a couple of on:do: in SmalltalkImage >> snapshot:anQuit: to collect the errors of all the startup scripts and then only show them after all other startupListItems are processed. All in all the behavior would not much differ from what is going on right now, but would prevent stupid users like me from losing a whole image. camillo |
|
|
It seems that pharo 1.3 introduced that the image quits if an error happens during startup. What are
the reasons for this? Or what's the state of the email below? Andrea Camillo Bruni schrieb: > While working on Coral we encountered a rather annoying behavior of pharo images when starting up. > > We wanted to check if we can debug the CoralScriptLoader, but of corse since this happens at image startup time this is not a good idea… > HOWEVER we were no longer able to run the image as it immediately crashes during the startup. > > Now I wonder if it would make sense to add a couple of on:do: in SmalltalkImage >> snapshot:anQuit: to collect the errors of all the startup scripts and then only show them after all other startupListItems are processed. > > All in all the behavior would not much differ from what is going on right now, but would prevent stupid users like me from losing a whole image. > > camillo > |
|
|
On 24 October 2011 11:40, Andrea Brühlmann <[hidden email]> wrote:
> It seems that pharo 1.3 introduced that the image quits if an error happens > during startup. What are the reasons for this? > The reasons are simple: if image fails to startup properly, there are no way to tell, if some services initialized properly or not (UI is one of them), and so, there are no any guarantees that image could run safely. So, the best thing which you can do is to write error to log and quit. This is because startup manager knows what to start-up and in what order, but it doesn't knows, how critical a given service for properly running the whole image. Therefore, if you don't handle startup errors in your service code, a startup manager has no other choice , but just leave to OS. > Or what's the state of the email below? > > Andrea > > > Camillo Bruni schrieb: >> >> While working on Coral we encountered a rather annoying behavior of pharo >> images when starting up. >> >> We wanted to check if we can debug the CoralScriptLoader, but of corse >> since this happens at image startup time this is not a good idea… HOWEVER we >> were no longer able to run the image as it immediately crashes during the >> startup. >> >> Now I wonder if it would make sense to add a couple of on:do: in >> SmalltalkImage >> snapshot:anQuit: to collect the errors of all the startup >> scripts and then only show them after all other startupListItems are >> processed. >> >> All in all the behavior would not much differ from what is going on right >> now, but would prevent stupid users like me from losing a whole image. >> >> camillo >> > > -- Best regards, Igor Stasenko. |
|
|
Sig,
All too true, and very pure. But what if I just want to save a package, or some data, that might be locked away in the image? Code is generally safe, since one can recover lost changes into a healthy image, but there can still be other data lurking in an image. A middle-ground approach would be to have command line option that lets the image run. One should run w/o it to bring errors to attention, but at least it would be possible to override and at least have an opportunity to recover endangered bits. Bill ________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Igor Stasenko [[hidden email]] Sent: Tuesday, October 25, 2011 9:40 AM To: [hidden email] Subject: Re: [Pharo-project] startup errors On 24 October 2011 11:40, Andrea Brühlmann <[hidden email]> wrote: > It seems that pharo 1.3 introduced that the image quits if an error happens > during startup. What are the reasons for this? > The reasons are simple: if image fails to startup properly, there are no way to tell, if some services initialized properly or not (UI is one of them), and so, there are no any guarantees that image could run safely. So, the best thing which you can do is to write error to log and quit. This is because startup manager knows what to start-up and in what order, but it doesn't knows, how critical a given service for properly running the whole image. Therefore, if you don't handle startup errors in your service code, a startup manager has no other choice , but just leave to OS. > Or what's the state of the email below? > > Andrea > > > Camillo Bruni schrieb: >> >> While working on Coral we encountered a rather annoying behavior of pharo >> images when starting up. >> >> We wanted to check if we can debug the CoralScriptLoader, but of corse >> since this happens at image startup time this is not a good idea… HOWEVER we >> were no longer able to run the image as it immediately crashes during the >> startup. >> >> Now I wonder if it would make sense to add a couple of on:do: in >> SmalltalkImage >> snapshot:anQuit: to collect the errors of all the startup >> scripts and then only show them after all other startupListItems are >> processed. >> >> All in all the behavior would not much differ from what is going on right >> now, but would prevent stupid users like me from losing a whole image. >> >> camillo >> > > -- Best regards, Igor Stasenko. |
|
|
On 25 October 2011 23:26, Schwab,Wilhelm K <[hidden email]> wrote:
> Sig, > > All too true, and very pure. But what if I just want to save a package, or some data, that might be locked away in the image? Code is generally safe, since one can recover lost changes into a healthy image, but there can still be other data lurking in an image. > > A middle-ground approach would be to have command line option that lets the image run. One should run w/o it to bring errors to attention, but at least it would be possible to override and at least have an opportunity to recover endangered bits. > look at settings, there's already an option to save a new version of image before quit. if you turn this option on, then any unhandled error will open a debugger if you open an image saved in such state. > Bill > > > ________________________________________ > From: [hidden email] [[hidden email]] On Behalf Of Igor Stasenko [[hidden email]] > Sent: Tuesday, October 25, 2011 9:40 AM > To: [hidden email] > Subject: Re: [Pharo-project] startup errors > > On 24 October 2011 11:40, Andrea Brühlmann <[hidden email]> wrote: >> It seems that pharo 1.3 introduced that the image quits if an error happens >> during startup. What are the reasons for this? >> > > The reasons are simple: > if image fails to startup properly, there are no way to tell, if some > services initialized properly or not (UI is one of them), > and so, there are no any guarantees that image could run safely. > So, the best thing which you can do is to write error to log and quit. > > This is because startup manager knows what to start-up and in what > order, but it doesn't knows, how critical a given service for properly > running the whole image. Therefore, if you don't handle startup errors > in your service code, a startup manager has no other choice , but just > leave to OS. > > >> Or what's the state of the email below? >> >> Andrea >> >> >> Camillo Bruni schrieb: >>> >>> While working on Coral we encountered a rather annoying behavior of pharo >>> images when starting up. >>> >>> We wanted to check if we can debug the CoralScriptLoader, but of corse >>> since this happens at image startup time this is not a good idea… HOWEVER we >>> were no longer able to run the image as it immediately crashes during the >>> startup. >>> >>> Now I wonder if it would make sense to add a couple of on:do: in >>> SmalltalkImage >> snapshot:anQuit: to collect the errors of all the startup >>> scripts and then only show them after all other startupListItems are >>> processed. >>> >>> All in all the behavior would not much differ from what is going on right >>> now, but would prevent stupid users like me from losing a whole image. >>> >>> camillo >>> >> >> > > > > -- > Best regards, > Igor Stasenko. > > > -- Best regards, Igor Stasenko. |
|
|
we should document that somewhere.
On Oct 25, 2011, at 11:40 PM, Igor Stasenko wrote: > On 25 October 2011 23:26, Schwab,Wilhelm K <[hidden email]> wrote: >> Sig, >> >> All too true, and very pure. But what if I just want to save a package, or some data, that might be locked away in the image? Code is generally safe, since one can recover lost changes into a healthy image, but there can still be other data lurking in an image. >> >> A middle-ground approach would be to have command line option that lets the image run. One should run w/o it to bring errors to attention, but at least it would be possible to override and at least have an opportunity to recover endangered bits. >> > look at settings, there's already an option to save a new version of > image before quit. > if you turn this option on, then any unhandled error will open a > debugger if you open an image saved in such state. > >> Bill >> >> >> ________________________________________ >> From: [hidden email] [[hidden email]] On Behalf Of Igor Stasenko [[hidden email]] >> Sent: Tuesday, October 25, 2011 9:40 AM >> To: [hidden email] >> Subject: Re: [Pharo-project] startup errors >> >> On 24 October 2011 11:40, Andrea Brühlmann <[hidden email]> wrote: >>> It seems that pharo 1.3 introduced that the image quits if an error happens >>> during startup. What are the reasons for this? >>> >> >> The reasons are simple: >> if image fails to startup properly, there are no way to tell, if some >> services initialized properly or not (UI is one of them), >> and so, there are no any guarantees that image could run safely. >> So, the best thing which you can do is to write error to log and quit. >> >> This is because startup manager knows what to start-up and in what >> order, but it doesn't knows, how critical a given service for properly >> running the whole image. Therefore, if you don't handle startup errors >> in your service code, a startup manager has no other choice , but just >> leave to OS. >> >> >>> Or what's the state of the email below? >>> >>> Andrea >>> >>> >>> Camillo Bruni schrieb: >>>> >>>> While working on Coral we encountered a rather annoying behavior of pharo >>>> images when starting up. >>>> >>>> We wanted to check if we can debug the CoralScriptLoader, but of corse >>>> since this happens at image startup time this is not a good idea… HOWEVER we >>>> were no longer able to run the image as it immediately crashes during the >>>> startup. >>>> >>>> Now I wonder if it would make sense to add a couple of on:do: in >>>> SmalltalkImage >> snapshot:anQuit: to collect the errors of all the startup >>>> scripts and then only show them after all other startupListItems are >>>> processed. >>>> >>>> All in all the behavior would not much differ from what is going on right >>>> now, but would prevent stupid users like me from losing a whole image. >>>> >>>> camillo >>>> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> >> > > > > -- > Best regards, > Igor Stasenko. > |
|
|
In reply to this post by Igor Stasenko
I tried it with this option now, but it did not solve the problem, because it just saved a new
version of the image and quit, but did not open a debugger. Opening the new version does the same as the original. Did I miss something? I would appreciate a command line option that either opens a debugger or ignores the errors, because like this you usually have a clean image but if you have a problem, you can open the image and do something. Andrea Igor Stasenko schrieb: > On 25 October 2011 23:26, Schwab,Wilhelm K <[hidden email]> wrote: >> Sig, >> >> All too true, and very pure. But what if I just want to save a package, or some data, that might be locked away in the image? Code is generally safe, since one can recover lost changes into a healthy image, but there can still be other data lurking in an image. >> >> A middle-ground approach would be to have command line option that lets the image run. One should run w/o it to bring errors to attention, but at least it would be possible to override and at least have an opportunity to recover endangered bits. >> > look at settings, there's already an option to save a new version of > image before quit. > if you turn this option on, then any unhandled error will open a > debugger if you open an image saved in such state. > >> Bill >> >> >> ________________________________________ >> From: [hidden email] [[hidden email]] On Behalf Of Igor Stasenko [[hidden email]] >> Sent: Tuesday, October 25, 2011 9:40 AM >> To: [hidden email] >> Subject: Re: [Pharo-project] startup errors >> >> On 24 October 2011 11:40, Andrea Brühlmann <[hidden email]> wrote: >>> It seems that pharo 1.3 introduced that the image quits if an error happens >>> during startup. What are the reasons for this? >>> >> The reasons are simple: >> if image fails to startup properly, there are no way to tell, if some >> services initialized properly or not (UI is one of them), >> and so, there are no any guarantees that image could run safely. >> So, the best thing which you can do is to write error to log and quit. >> >> This is because startup manager knows what to start-up and in what >> order, but it doesn't knows, how critical a given service for properly >> running the whole image. Therefore, if you don't handle startup errors >> in your service code, a startup manager has no other choice , but just >> leave to OS. >> >> >>> Or what's the state of the email below? >>> >>> Andrea >>> >>> >>> Camillo Bruni schrieb: >>>> While working on Coral we encountered a rather annoying behavior of pharo >>>> images when starting up. >>>> >>>> We wanted to check if we can debug the CoralScriptLoader, but of corse >>>> since this happens at image startup time this is not a good idea… HOWEVER we >>>> were no longer able to run the image as it immediately crashes during the >>>> startup. >>>> >>>> Now I wonder if it would make sense to add a couple of on:do: in >>>> SmalltalkImage >> snapshot:anQuit: to collect the errors of all the startup >>>> scripts and then only show them after all other startupListItems are >>>> processed. >>>> >>>> All in all the behavior would not much differ from what is going on right >>>> now, but would prevent stupid users like me from losing a whole image. >>>> >>>> camillo >>>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> >> > > > -- AB | ANDREA BRÜHLMANN · SOFTWARE ENGINEER | NETSTYLE · TERRASSENWEG 18 · CH-3012 BERN | TEL +41 31 356 42 54 · FAX +41 31 356 42 51 | WWW.NETSTYLE.CH · [hidden email] |
|
|
On 26 October 2011 11:51, Andrea Brühlmann <[hidden email]> wrote:
> I tried it with this option now, but it did not solve the problem, because > it just saved a new version of the image and quit, but did not open a > debugger. Opening the new version does the same as the original. Did I miss > something? > It should open a debugger. if not, then this is a bug :) It might be, that if error happens in startup phase, then it is not opens a debugger. > I would appreciate a command line option that either opens a debugger or > ignores the errors, because like this you usually have a clean image but if > you have a problem, you can open the image and do something. > > Andrea > > Igor Stasenko schrieb: >> >> On 25 October 2011 23:26, Schwab,Wilhelm K <[hidden email]> wrote: >>> >>> Sig, >>> >>> All too true, and very pure. But what if I just want to save a package, >>> or some data, that might be locked away in the image? Code is generally >>> safe, since one can recover lost changes into a healthy image, but there can >>> still be other data lurking in an image. >>> >>> A middle-ground approach would be to have command line option that lets >>> the image run. One should run w/o it to bring errors to attention, but at >>> least it would be possible to override and at least have an opportunity to >>> recover endangered bits. >>> >> look at settings, there's already an option to save a new version of >> image before quit. >> if you turn this option on, then any unhandled error will open a >> debugger if you open an image saved in such state. >> >>> Bill >>> >>> >>> ________________________________________ >>> From: [hidden email] >>> [[hidden email]] On Behalf Of Igor Stasenko >>> [[hidden email]] >>> Sent: Tuesday, October 25, 2011 9:40 AM >>> To: [hidden email] >>> Subject: Re: [Pharo-project] startup errors >>> >>> On 24 October 2011 11:40, Andrea Brühlmann <[hidden email]> >>> wrote: >>>> >>>> It seems that pharo 1.3 introduced that the image quits if an error >>>> happens >>>> during startup. What are the reasons for this? >>>> >>> The reasons are simple: >>> if image fails to startup properly, there are no way to tell, if some >>> services initialized properly or not (UI is one of them), >>> and so, there are no any guarantees that image could run safely. >>> So, the best thing which you can do is to write error to log and quit. >>> >>> This is because startup manager knows what to start-up and in what >>> order, but it doesn't knows, how critical a given service for properly >>> running the whole image. Therefore, if you don't handle startup errors >>> in your service code, a startup manager has no other choice , but just >>> leave to OS. >>> >>> >>>> Or what's the state of the email below? >>>> >>>> Andrea >>>> >>>> >>>> Camillo Bruni schrieb: >>>>> >>>>> While working on Coral we encountered a rather annoying behavior of >>>>> pharo >>>>> images when starting up. >>>>> >>>>> We wanted to check if we can debug the CoralScriptLoader, but of corse >>>>> since this happens at image startup time this is not a good idea… >>>>> HOWEVER we >>>>> were no longer able to run the image as it immediately crashes during >>>>> the >>>>> startup. >>>>> >>>>> Now I wonder if it would make sense to add a couple of on:do: in >>>>> SmalltalkImage >> snapshot:anQuit: to collect the errors of all the >>>>> startup >>>>> scripts and then only show them after all other startupListItems are >>>>> processed. >>>>> >>>>> All in all the behavior would not much differ from what is going on >>>>> right >>>>> now, but would prevent stupid users like me from losing a whole image. >>>>> >>>>> camillo >>>>> >>>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >>> >>> >> >> >> > > -- > AB | ANDREA BRÜHLMANN · SOFTWARE ENGINEER > | NETSTYLE · TERRASSENWEG 18 · CH-3012 BERN > | TEL +41 31 356 42 54 · FAX +41 31 356 42 51 > | WWW.NETSTYLE.CH · [hidden email] > > -- Best regards, Igor Stasenko. |
|
|
I tested it a bit in a fresh 1.3 image and opened the issue 5045, maybe
we can continue the discussion there. The feature would be great! Andrea Igor Stasenko schrieb: > On 26 October 2011 11:51, Andrea Brühlmann <[hidden email]> wrote: > >> I tried it with this option now, but it did not solve the problem, because >> it just saved a new version of the image and quit, but did not open a >> debugger. Opening the new version does the same as the original. Did I miss >> something? >> >> > It should open a debugger. if not, then this is a bug :) > It might be, that if error happens in startup phase, then it is not > opens a debugger. > > >> I would appreciate a command line option that either opens a debugger or >> ignores the errors, because like this you usually have a clean image but if >> you have a problem, you can open the image and do something. >> >> Andrea >> >> Igor Stasenko schrieb: >> >>> On 25 October 2011 23:26, Schwab,Wilhelm K <[hidden email]> wrote: >>> >>>> Sig, >>>> >>>> All too true, and very pure. But what if I just want to save a package, >>>> or some data, that might be locked away in the image? Code is generally >>>> safe, since one can recover lost changes into a healthy image, but there can >>>> still be other data lurking in an image. >>>> >>>> A middle-ground approach would be to have command line option that lets >>>> the image run. One should run w/o it to bring errors to attention, but at >>>> least it would be possible to override and at least have an opportunity to >>>> recover endangered bits. >>>> >>>> >>> look at settings, there's already an option to save a new version of >>> image before quit. >>> if you turn this option on, then any unhandled error will open a >>> debugger if you open an image saved in such state. >>> >>> >>>> Bill >>>> >>>> >>>> ________________________________________ >>>> From: [hidden email] >>>> [[hidden email]] On Behalf Of Igor Stasenko >>>> [[hidden email]] >>>> Sent: Tuesday, October 25, 2011 9:40 AM >>>> To: [hidden email] >>>> Subject: Re: [Pharo-project] startup errors >>>> >>>> On 24 October 2011 11:40, Andrea Brühlmann <[hidden email]> >>>> wrote: >>>> >>>>> It seems that pharo 1.3 introduced that the image quits if an error >>>>> happens >>>>> during startup. What are the reasons for this? >>>>> >>>>> >>>> The reasons are simple: >>>> if image fails to startup properly, there are no way to tell, if some >>>> services initialized properly or not (UI is one of them), >>>> and so, there are no any guarantees that image could run safely. >>>> So, the best thing which you can do is to write error to log and quit. >>>> >>>> This is because startup manager knows what to start-up and in what >>>> order, but it doesn't knows, how critical a given service for properly >>>> running the whole image. Therefore, if you don't handle startup errors >>>> in your service code, a startup manager has no other choice , but just >>>> leave to OS. >>>> >>>> >>>> >>>>> Or what's the state of the email below? >>>>> >>>>> Andrea >>>>> >>>>> >>>>> Camillo Bruni schrieb: >>>>> >>>>>> While working on Coral we encountered a rather annoying behavior of >>>>>> pharo >>>>>> images when starting up. >>>>>> >>>>>> We wanted to check if we can debug the CoralScriptLoader, but of corse >>>>>> since this happens at image startup time this is not a good idea… >>>>>> HOWEVER we >>>>>> were no longer able to run the image as it immediately crashes during >>>>>> the >>>>>> startup. >>>>>> >>>>>> Now I wonder if it would make sense to add a couple of on:do: in >>>>>> SmalltalkImage >> snapshot:anQuit: to collect the errors of all the >>>>>> startup >>>>>> scripts and then only show them after all other startupListItems are >>>>>> processed. >>>>>> >>>>>> All in all the behavior would not much differ from what is going on >>>>>> right >>>>>> now, but would prevent stupid users like me from losing a whole image. >>>>>> >>>>>> camillo >>>>>> >>>>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>>> >>>> >>>> >>> >>> >> -- >> AB | ANDREA BRÜHLMANN · SOFTWARE ENGINEER >> | NETSTYLE · TERRASSENWEG 18 · CH-3012 BERN >> | TEL +41 31 356 42 54 · FAX +41 31 356 42 51 >> | WWW.NETSTYLE.CH · [hidden email] >> >> >> > > > > |
|
Administrator
|
In reply to this post by Camillo Bruni
This was the issue that caused me to learn VM debugging :) http://forum.world.st/Oops-I-put-a-halt-in-a-startup-method-td3800163.html
Cheers,
Sean |
|
Administrator
|
In reply to this post by Igor Stasenko
I don't always know I'm going to destroy my image in advance :) It would be nice to have a way to recover anyway.
Cheers,
Sean |
|
|
We invented a way to hack an image with Camillo. Instead of hacking VM :)
THis is easy and fast. On 2 December 2011 15:45, Sean P. DeNigris <[hidden email]> wrote: > > Igor Stasenko wrote >> >> look at settings, there's already an option to save a new version of >> image before quit. >> if you turn this option on, then any unhandled error will open a >> debugger if you open an image saved in such state. >> > > I don't always know I'm going to destroy my image in advance :) It would be > nice to have a way to recover anyway. > > -- > View this message in context: http://forum.world.st/startup-errors-tp3736966p4147365.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Best regards, Igor Stasenko. |
|
|
In reply to this post by Sean P. DeNigris
We should enhance the recover last changes to be able to pick a different change file too.
Stef On Dec 2, 2011, at 3:45 PM, Sean P. DeNigris wrote: > > Igor Stasenko wrote >> >> look at settings, there's already an option to save a new version of >> image before quit. >> if you turn this option on, then any unhandled error will open a >> debugger if you open an image saved in such state. >> > > I don't always know I'm going to destroy my image in advance :) It would be > nice to have a way to recover anyway. > > -- > View this message in context: http://forum.world.st/startup-errors-tp3736966p4147365.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > |
|
Administrator
|
In reply to this post by Igor Stasenko
Cool! What does it mean to "hack an image"? When you wrote: it sounded like this would only work for experiments where you were expecting you might cause an error during startup. What I'm suggesting (and I thought the OP was requesting) is a way to recover after accidentally causing an error at startup. Now there is no way to go back in and set the setting, so the image is lost, unless you hack the VM. Or is there currently another way?
Cheers,
Sean |
|
|
+1 on the option being too late. Given my dislike of silent failures, I can't object to some means of drawing attention to the problem, and failure to start certainly does that. However, there should be a way to allow the image to start in the (likely?) event that it can assist in its repair or replacement.
Bill ________________________________________ From: [hidden email] [[hidden email]] on behalf of Sean P. DeNigris [[hidden email]] Sent: Sunday, December 04, 2011 1:46 PM To: [hidden email] Subject: Re: [Pharo-project] startup errors Igor Stasenko wrote > > We invented a way to hack an image with Camillo. Instead of hacking VM :) > THis is easy and fast. > Cool! What does it mean to "hack an image"? When you wrote: Igor Stasenko wrote > > look at settings, there's already an option to save a new version of > image before quit. > if you turn this option on, then any unhandled error will open a > debugger if you open an image saved in such state. > it sounded like this would only work for experiments where you were expecting you might cause an error during startup. What I'm suggesting (and I thought the OP was requesting) is a way to recover after accidentally causing an error at startup. Now there is no way to go back in and set the setting, so the image is lost, unless you hack the VM. Or is there currently another way? -- View this message in context: http://forum.world.st/startup-errors-tp3736966p4157667.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. |
|
|
In reply to this post by Sean P. DeNigris
On 4 December 2011 20:46, Sean P. DeNigris <[hidden email]> wrote:
> > Igor Stasenko wrote >> >> We invented a way to hack an image with Camillo. Instead of hacking VM :) >> THis is easy and fast. >> > Cool! What does it mean to "hack an image"? > > When you wrote: > > Igor Stasenko wrote >> >> look at settings, there's already an option to save a new version of >> image before quit. >> if you turn this option on, then any unhandled error will open a >> debugger if you open an image saved in such state. >> > it sounded like this would only work for experiments where you were > expecting you might cause an error during startup. What I'm suggesting (and > I thought the OP was requesting) is a way to recover after accidentally > causing an error at startup. Now there is no way to go back in and set the > setting, so the image is lost, unless you hack the VM. Or is there currently > another way? > bytecode of unwanted method with ^ self bytecode, in that way image avoiding entering code which leads to failure. To identify specific method, you can search image file for unique sequence of bytecodes :) > -- > View this message in context: http://forum.world.st/startup-errors-tp3736966p4157667.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko. |
|
|
In reply to this post by Andrea Brühlmann-2
Hi there,
Could anyone please have a look at issue 5045? I am running into big troubles from time to time because of images that cannot be opened anymore because there happens an error somewhere during startup. The discussed option would allow image recovery without hacking the bytecode! Thanks Andrea Andrea Brühlmann schrieb: > I tested it a bit in a fresh 1.3 image and opened the issue 5045, > maybe we can continue the discussion there. The feature would be great! > > Andrea > > > > Igor Stasenko schrieb: >> On 26 October 2011 11:51, Andrea Brühlmann <[hidden email]> >> wrote: >> >>> I tried it with this option now, but it did not solve the problem, >>> because >>> it just saved a new version of the image and quit, but did not open a >>> debugger. Opening the new version does the same as the original. Did >>> I miss >>> something? >>> >>> >> It should open a debugger. if not, then this is a bug :) >> It might be, that if error happens in startup phase, then it is not >> opens a debugger. >> >> >>> I would appreciate a command line option that either opens a >>> debugger or >>> ignores the errors, because like this you usually have a clean image >>> but if >>> you have a problem, you can open the image and do something. >>> >>> Andrea >>> >>> Igor Stasenko schrieb: >>> >>>> On 25 October 2011 23:26, Schwab,Wilhelm K <[hidden email]> >>>> wrote: >>>> >>>>> Sig, >>>>> >>>>> All too true, and very pure. But what if I just want to save a >>>>> package, >>>>> or some data, that might be locked away in the image? Code is >>>>> generally >>>>> safe, since one can recover lost changes into a healthy image, but >>>>> there can >>>>> still be other data lurking in an image. >>>>> >>>>> A middle-ground approach would be to have command line option that >>>>> lets >>>>> the image run. One should run w/o it to bring errors to >>>>> attention, but at >>>>> least it would be possible to override and at least have an >>>>> opportunity to >>>>> recover endangered bits. >>>>> >>>>> >>>> look at settings, there's already an option to save a new version of >>>> image before quit. >>>> if you turn this option on, then any unhandled error will open a >>>> debugger if you open an image saved in such state. >>>> >>>> >>>>> Bill >>>>> >>>>> >>>>> ________________________________________ >>>>> From: [hidden email] >>>>> [[hidden email]] On Behalf Of Igor >>>>> Stasenko >>>>> [[hidden email]] >>>>> Sent: Tuesday, October 25, 2011 9:40 AM >>>>> To: [hidden email] >>>>> Subject: Re: [Pharo-project] startup errors >>>>> >>>>> On 24 October 2011 11:40, Andrea Brühlmann <[hidden email]> >>>>> wrote: >>>>> >>>>>> It seems that pharo 1.3 introduced that the image quits if an error >>>>>> happens >>>>>> during startup. What are the reasons for this? >>>>>> >>>>>> >>>>> The reasons are simple: >>>>> if image fails to startup properly, there are no way to tell, if some >>>>> services initialized properly or not (UI is one of them), >>>>> and so, there are no any guarantees that image could run safely. >>>>> So, the best thing which you can do is to write error to log and >>>>> quit. >>>>> >>>>> This is because startup manager knows what to start-up and in what >>>>> order, but it doesn't knows, how critical a given service for >>>>> properly >>>>> running the whole image. Therefore, if you don't handle startup >>>>> errors >>>>> in your service code, a startup manager has no other choice , but >>>>> just >>>>> leave to OS. >>>>> >>>>> >>>>> >>>>>> Or what's the state of the email below? >>>>>> >>>>>> Andrea >>>>>> >>>>>> >>>>>> Camillo Bruni schrieb: >>>>>> >>>>>>> While working on Coral we encountered a rather annoying behavior of >>>>>>> pharo >>>>>>> images when starting up. >>>>>>> >>>>>>> We wanted to check if we can debug the CoralScriptLoader, but of >>>>>>> corse >>>>>>> since this happens at image startup time this is not a good idea… >>>>>>> HOWEVER we >>>>>>> were no longer able to run the image as it immediately crashes >>>>>>> during >>>>>>> the >>>>>>> startup. >>>>>>> >>>>>>> Now I wonder if it would make sense to add a couple of on:do: in >>>>>>> SmalltalkImage >> snapshot:anQuit: to collect the errors of all the >>>>>>> startup >>>>>>> scripts and then only show them after all other startupListItems >>>>>>> are >>>>>>> processed. >>>>>>> >>>>>>> All in all the behavior would not much differ from what is going on >>>>>>> right >>>>>>> now, but would prevent stupid users like me from losing a whole >>>>>>> image. >>>>>>> >>>>>>> camillo >>>>>>> >>>>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> -- >>> AB | ANDREA BRÜHLMANN · SOFTWARE ENGINEER >>> | NETSTYLE · TERRASSENWEG 18 · CH-3012 BERN >>> | TEL +41 31 356 42 54 · FAX +41 31 356 42 51 >>> | WWW.NETSTYLE.CH · [hidden email] >>> >>> >>> >> >> >> >> > > > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |