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 <[email protected]>
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 <[email protected]>
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: [email protected]
[[email protected]] On Behalf Of Igor
Stasenko
[[email protected]]
Sent: Tuesday, October 25, 2011 9:40 AM
To: [email protected]
Subject: Re: [Pharo-project] startup errors
On 24 October 2011 11:40, Andrea Brühlmann <[email protected]>
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 · [email protected]
