Sign of Impending Iceberg Doom on Pharo 6.1
Sometimes while working in Iceberg on 6.1, I see a progress bar(s) like the following: <http://forum.world.st/file/t128965/Screenshot_2018-08-24_12.jpeg> This seems to usually signal that a crash is not far away. It's doubly concerning because there is no clear way to stop the troubled process (interrupts often bring up a debugger on something else) and because, since one is now unable to save any code, it's unclear how to start over easily in a new image. In an extreme scenario, I recently panicked during such an experience and accidentally clicked "Save" instead of "Save Asâ¦" resulting in an image that took hours worth of code (I know maybe not a great practice) with it to the grave. Any idea why this happens or what we might be able to do anything about it? p.s. I was so concerned that I immediately resolved to move to Pharo 7, but that turned out not to be an option do to the recently reported bug with extension methods (that don't exactly match the package name) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Hi Sean, On Fri, Aug 24, 2018 at 10:03 AM Sean P. DeNigris <sean@clipperadams.com> wrote:
Sometimes while working in Iceberg on 6.1, I see a progress bar(s) like the following: <http://forum.world.st/file/t128965/Screenshot_2018-08-24_12.jpeg>
This seems to usually signal that a crash is not far away. It's doubly concerning because there is no clear way to stop the troubled process (interrupts often bring up a debugger on something else) and because, since one is now unable to save any code, it's unclear how to start over easily in a new image. In an extreme scenario, I recently panicked during such an experience and accidentally clicked "Save" instead of "Save Asâ¦" resulting in an image that took hours worth of code (I know maybe not a great practice) with it to the grave.
Any idea why this happens or what we might be able to do anything about it?
No. Yes. Indirectly I hope to help debug this. I am nearly finished with an error handling facility in the VM for FFI calls that will fail an FFI callout primitive with an error code indicating the kind of exception and the pc. This should at least stop the system from crashing and give us an improved ability to make sense of the exception; at least we'll be able to examine the arguments to the call. More details as I roll out the facility. It will require integrating some support code, rewriting FFI callout signatures to include an error code, etc. p.s. I was so concerned that I immediately resolved to move to Pharo 7, but
that turned out not to be an option do to the recently reported bug with extension methods (that don't exactly match the package name)
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
_,,,^..^,,,_ best, Eliot
On Sat, 25 Aug 2018 at 01:40, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Sean, On Fri, Aug 24, 2018 at 10:03 AM Sean P. DeNigris <sean@clipperadams.com> wrote:
Sometimes while working in Iceberg on 6.1, I see a progress bar(s) like the following: <http://forum.world.st/file/t128965/Screenshot_2018-08-24_12.jpeg>
This seems to usually signal that a crash is not far away.
Do you mean seconds or minutes or more away from a crash?
It's doubly concerning because there is no clear way to stop the troubled
process (interrupts often bring up a debugger on something else) and because, since one is now unable to save any code, it's unclear how to start over easily in a new image.
Just some general ideas (you may have already considered) The string "Diffing..." appears in only one location in MCPatch>>initializeWithBase:target: I'm not clear on the behaviour of #on:displayProgress: whether its possible some inside loop can make that string appear multiple times, or whether it indicates #initializeWithBase:target: is being called multiple times. A specific check there for an escape key-combo might help debug this. Or a class variable reset from Iceberg that halts when it exceeds a limit on the number of loops. Or log to file five or so levels of "thisContext senders senders etc" for post crash analysis to help isolate the loop. cheers -ben P.S. While I was browsing senders-of-senders-of-senders I quickly got lost and wondered if a tool that graphically showed a senders-tree might be a useful demo for Diagrammer.
I ve'seen this problem also but never been able to find a reproducible case. I've recall to see it even before Iceberg, so to me it looks like some Monticello issue. I always had the impression that Monticello it's trying to regenerate all the code definitions instead of the changes. Running exactly the same code snippet again usually worked for me. Anyways if someone had a reproducible case just let us know. On Fri, Aug 24, 2018 at 2:03 PM Sean P. DeNigris <sean@clipperadams.com> wrote:
Sometimes while working in Iceberg on 6.1, I see a progress bar(s) like the following: <http://forum.world.st/file/t128965/Screenshot_2018-08-24_12.jpeg>
This seems to usually signal that a crash is not far away. It's doubly concerning because there is no clear way to stop the troubled process (interrupts often bring up a debugger on something else) and because, since one is now unable to save any code, it's unclear how to start over easily in a new image. In an extreme scenario, I recently panicked during such an experience and accidentally clicked "Save" instead of "Save Asâ¦" resulting in an image that took hours worth of code (I know maybe not a great practice) with it to the grave.
Any idea why this happens or what we might be able to do anything about it?
p.s. I was so concerned that I immediately resolved to move to Pharo 7, but that turned out not to be an option do to the recently reported bug with extension methods (that don't exactly match the package name)
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Hi, Please take into account that the iceberg version present on Pharo 6.1 is obsolete and most of the problems seen there should be solved in the version present on Pharo 7. You would ask why being an obsolete version we do not backport the good version for Pharo 6.1 and the answer is: Iceberg 1+ is a huge change and it may broke current P6.1 behaviour so we (I) decided not to do it. Instead, people using intensively iceberg are recommended to install themselves the correct version following the instructions here: https://github.com/pharo-vcs/iceberg#update-iceberg <https://github.com/pharo-vcs/iceberg#update-iceberg> <https://github.com/pharo-vcs/iceberg#update-iceberg> <https://github.com/pharo-vcs/iceberg#update-iceberg>Cheers, Esteban
On 24 Aug 2018, at 19:45, Gabriel Cotelli <g.cotelli@gmail.com> wrote:
I ve'seen this problem also but never been able to find a reproducible case. I've recall to see it even before Iceberg, so to me it looks like some Monticello issue. I always had the impression that Monticello it's trying to regenerate all the code definitions instead of the changes. Running exactly the same code snippet again usually worked for me.
Anyways if someone had a reproducible case just let us know.
On Fri, Aug 24, 2018 at 2:03 PM Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>> wrote: Sometimes while working in Iceberg on 6.1, I see a progress bar(s) like the following: <http://forum.world.st/file/t128965/Screenshot_2018-08-24_12.jpeg <http://forum.world.st/file/t128965/Screenshot_2018-08-24_12.jpeg>>
This seems to usually signal that a crash is not far away. It's doubly concerning because there is no clear way to stop the troubled process (interrupts often bring up a debugger on something else) and because, since one is now unable to save any code, it's unclear how to start over easily in a new image. In an extreme scenario, I recently panicked during such an experience and accidentally clicked "Save" instead of "Save Asâ¦" resulting in an image that took hours worth of code (I know maybe not a great practice) with it to the grave.
Any idea why this happens or what we might be able to do anything about it?
p.s. I was so concerned that I immediately resolved to move to Pharo 7, but that turned out not to be an option do to the recently reported bug with extension methods (that don't exactly match the package name)
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html>
EstebanLM wrote
You would ask why being an obsolete version we do not backport the good version for Pharo 6.1
That is totally understandable. EstebanLM wrote
recommended to install themselves the correct version...
Ah! I didn't realize there was still a viable upgrade path. I will check that out! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Le 24/08/2018 à 19:03, Sean P. DeNigris a écrit :
Sometimes while working in Iceberg on 6.1, I see a progress bar(s) like the following: <http://forum.world.st/file/t128965/Screenshot_2018-08-24_12.jpeg>
This seems to usually signal that a crash is not far away. It's doubly concerning because there is no clear way to stop the troubled process (interrupts often bring up a debugger on something else) and because, since one is now unable to save any code, it's unclear how to start over easily in a new image. In an extreme scenario, I recently panicked during such an experience and accidentally clicked "Save" instead of "Save Asâ¦" resulting in an image that took hours worth of code (I know maybe not a great practice) with it to the grave.
Any idea why this happens or what we might be able to do anything about it?
p.s. I was so concerned that I immediately resolved to move to Pharo 7, but that turned out not to be an option do to the recently reported bug with extension methods (that don't exactly match the package name)
Hi, IIRC the problem only happens when the commit windows is maximize. Something happen, maybe the progress bar updating launch a redraw of the morph, and if the iceberg window is under the progress bar it also try to redraw it but for that it snapshots methods etc... When I did not maximized my windows and kept them in the center it was fine.
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
-- Cyril Ferlicot https://ferlicot.fr
On 24 Aug 2018, at 20:41, Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
Le 24/08/2018 à 19:03, Sean P. DeNigris a écrit :
Sometimes while working in Iceberg on 6.1, I see a progress bar(s) like the following: <http://forum.world.st/file/t128965/Screenshot_2018-08-24_12.jpeg>
This seems to usually signal that a crash is not far away. It's doubly concerning because there is no clear way to stop the troubled process (interrupts often bring up a debugger on something else) and because, since one is now unable to save any code, it's unclear how to start over easily in a new image. In an extreme scenario, I recently panicked during such an experience and accidentally clicked "Save" instead of "Save Asâ¦" resulting in an image that took hours worth of code (I know maybe not a great practice) with it to the grave.
Any idea why this happens or what we might be able to do anything about it?
p.s. I was so concerned that I immediately resolved to move to Pharo 7, but that turned out not to be an option do to the recently reported bug with extension methods (that don't exactly match the package name)
Hi,
IIRC the problem only happens when the commit windows is maximize. Something happen, maybe the progress bar updating launch a redraw of the morph, and if the iceberg window is under the progress bar it also try to redraw it but for that it snapshots methods etc...
When I did not maximized my windows and kept them in the center it was fine.
Yes, afaik that problem was related with redrawing of some glamour lists and an infinite loop triggered by the old iceberg UI. Esteban
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
-- Cyril Ferlicot https://ferlicot.fr
participants (6)
-
Ben Coman -
Cyril Ferlicot D. -
Eliot Miranda -
Esteban Lorenzano -
Gabriel Cotelli -
Sean P. DeNigris