Sven, I was taught to never trap Exception - Error is ok to trap, AFAIK. Beyond that, where does this code live? How often/when does it execute? Exception handlers are expensive to set up and even more expensive when used.
This is not really an exceptional condition; it is a predictable failure and one that can be handled locally rather than needing to be left to the application layer. IMHO, it is not a good place to use an exception handler. Hanging in place of opening a walkback is bad. I suggest fixing that first (the printing defect seems to be a nice way top reproduce the hang that should not happen), and THEN fix the #printOn: so the walkback does not appear. BTW, so much for my inability to reproduce this. Print-it in my 1.4 image did not go well - had to kill the vm, so it happens on Linux too. Bill ________________________________________ From: [email protected] [[email protected]] on behalf of Sven Van Caekenberghe [[email protected]] Sent: Friday, December 02, 2011 6:08 PM To: [email protected] Subject: Re: [Pharo-project] VM freezes sending #basicNew to Stream subclass Again, thanks a lot Nicolas for digging in this problem and finding a solution. I think your solution looks good. But you are essentially avoiding the problem that there is an object involved that cannot print itself. Marcus tried to tackle that problems, and I think that he was right to change the printOn: so that it works and does not have side effects. Would it not be possible to have a 'safe' way to print instances ? [ object printString ] on: Exception do: [ ' unprintable object of class ', object class ] Sven On 02 Dec 2011, at 23:52, Nicolas Cellier wrote: > I suggest to change the #standardMessageText to rather print signaller class > Attached a change set, please open an issue and review carefully. > > Nicolas > > 2011/12/2 Nicolas Cellier <[email protected]>: >> 2011/12/2 Nicolas Cellier <[email protected]>: >>> 2011/12/2 Marcus Denker <[email protected]>: >>>> Hi, >>>> >>>> We had a look and the problem is that printOn: on Stream is defined to >>>> print the contents of the Stream even though it might >>>> not be initialized yet (e.g. when creating a Stream instance with >>>> #basicNew). >>>> >>>> The simplest solution is to just not print the contents of Streams in >>>> #printOn: >>>> >>>> http://code.google.com/p/pharo/issues/detail?id=5047 >>>> >>>> Stream should not print its contents in printOn: >>>> >>>> Reason: >>>> >>>> => Debugging leads to change the state of Stream when looking at it >>>> => Network streams load all content >>>> => unitialized Streams has undefined behavior for printing >>>> >>>> Solution: remove #printOn: >>>> >>> >>> No, no, no I don't agree, you are hiding the main problem, not solving it. >>> The main problem is not this error, the main problem is that the >>> debugger does not appear when it should. >>> >>> Nicolas >>> >> >> The problem with SubclassResponsibility is its #description. >> The #description method will send #messageText which will send >> #standardMessageText which will try to print the signaller which is >> the unprintable (not initialized) Stream basicNew. >> Thus when the UnhandledError triggers a (Smalltalk tools debugError: >> anException) it fails with a new SubclassResponsibility error... >> This does not happen previously with an ordinary Error which has a >> more robust #description, thus SubclassResponsibility effectively >> introduced a new weakness. >> >> With current state of debugger in Pharo 1.4, this is not a pleasure, >> IMO it's very urgent to fix it. >> Who ever messed with Debugger/Context or any such dangerous internals >> has a FirstClassResponsibility to make it work or revert. >> >> Nicolas >> >>>> On Fri, Dec 2, 2011 at 9:08 AM, Stéphane Ducasse >>>> <[email protected]> wrote: >>>>>>>> >>>>>>>> I only had a look in Pharo 1.4 >>>>>>>> It sounds like a subtle bug related to introduction of >>>>>>>> SubclassResponsibility in Pharo. >>>>>>>> If you revert Object>>subclassResponsibility to its previous version >>>>>>>> you get a more reliable error. >>>>>>> >>>>>>> What would be your hypothesis? Because I'm stuck. >>>>>>> error: is also signaling an exception >>>>>>> >>>>>>> error: aString >>>>>>> "Throw a generic Error exception." >>>>>>> >>>>>>> ^Error new signal: aString >>>>>>> >>>>>>> So I wonder why one is more robust. >>>>>>> >>>>>> >>>>>> I'm stuck too, and the Debugger is currently unusable in Pharo 1.4 (I >>>>>> just can't step over…) >>>>> >>>>> Strange. Because I use it. >>>>> Do you have a scenario that we can focus on to fix the problem you see. >>>>> >>>>> >>>>>> I give up. I only had time for an easy task... >>>>>> >>>>>> Nicolas >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Nicolas >>>>>>>> >>>>>>>> 2011/12/1 Larry White <[email protected]>: >>>>>>>>> I was able to replicate with a clean version of the Seaside 3.0.6 One >>>>>>>>> Click >>>>>>>>> download by executing Stream #basicNew in a workspace. It did work a >>>>>>>>> couple >>>>>>>>> times ok using "do it" from the menu, but seems to lock pretty >>>>>>>>> regularly >>>>>>>>> using print or explore keyboard shortcuts. >>>>>>>>> >>>>>>>>> thanks. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Dec 1, 2011 at 1:33 PM, Larry White <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> I can do it with control-P (print) in the Workspace. I just did it >>>>>>>>>> with a >>>>>>>>>> single try, though sometimes it takes more than one. Speed isn't an >>>>>>>>>> issue, >>>>>>>>>> I can wait 10 minutes and see it happen sometimes.. >>>>>>>>>> >>>>>>>>>> I have to take a break now, but when I get a few minutes, I'll try >>>>>>>>>> again >>>>>>>>>> with a fresh install of the latest Seaside one-click for the mac. >>>>>>>>>> >>>>>>>>>> thanks. >>>>>>>>>> >>>>>>>>>> On Thu, Dec 1, 2011 at 1:20 PM, Schwab,Wilhelm K >>>>>>>>>> <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> I just tried to hang 1.1.1 (using a traditional linux vm) and a 1.4 >>>>>>>>>>> image >>>>>>>>>>> with a Cog vm (also linux). No problems, but I do have questions >>>>>>>>>>> that might >>>>>>>>>>> be important to others trying to reproduce it: >>>>>>>>>>> >>>>>>>>>>> (1) how fast do you do this? >>>>>>>>>>> (2) do you inspect the instances, or just let them get gc'd >>>>>>>>>>> immediately? >>>>>>>>>>> >>>>>>>>>>> Bill >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ________________________________ >>>>>>>>>>> From: [email protected] >>>>>>>>>>> [[email protected]] on behalf of Larry >>>>>>>>>>> White >>>>>>>>>>> [[email protected]] >>>>>>>>>>> Sent: Thursday, December 01, 2011 12:56 PM >>>>>>>>>>> To: [email protected] >>>>>>>>>>> Subject: Re: [Pharo-project] VM freezes sending #basicNew to Stream >>>>>>>>>>> subclass >>>>>>>>>>> >>>>>>>>>>> I can do it with >>>>>>>>>>> >>>>>>>>>>> Stream basicNew. >>>>>>>>>>> >>>>>>>>>>> but I have to invoke it twice. The first time it works ok. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Dec 1, 2011 at 12:48 PM, Stéphane Ducasse >>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>> gary >>>>>>>>>>>> >>>>>>>>>>>> can you post the smallest code that makes the system hangs? >>>>>>>>>>>> >>>>>>>>>>>> Stef >>>>>>>>>>>> >>>>>>>>>>>> On Dec 1, 2011, at 4:48 PM, Larry White wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> Throwing this out there because it may be a bug. >>>>>>>>>>>>> >>>>>>>>>>>>> I'm running the Seaside one-click install on OS X Lion. >>>>>>>>>>>>> Pharo1.3 >>>>>>>>>>>>> Latest update: #13302 >>>>>>>>>>>>> >>>>>>>>>>>>> I can reliably cause my VM to freeze up and need to Force-Quit it >>>>>>>>>>>>> from >>>>>>>>>>>>> the OS. >>>>>>>>>>>>> >>>>>>>>>>>>> I'm implementing (copying) the probability logic from the blue >>>>>>>>>>>>> book. >>>>>>>>>>>>> When I tried to create an instance of the Binomial class, the >>>>>>>>>>>>> system hung. I >>>>>>>>>>>>> can replicate the problem by sending the message #basicNew to >>>>>>>>>>>>> ProbabilityDistribution. ProbabilityDistribution is a direct >>>>>>>>>>>>> subclass of >>>>>>>>>>>>> Stream and I haven't overridden or modified #basicNew. >>>>>>>>>>>>> >>>>>>>>>>>>> What's happening is that it fails in the BlockClosure [anObject >>>>>>>>>>>>> doit], >>>>>>>>>>>>> but only when I instantiate a member of this particular class >>>>>>>>>>>>> hierarchy. In >>>>>>>>>>>>> the probability classes, a #doIt in a Workspace hits the line >>>>>>>>>>>>> "self suspend" >>>>>>>>>>>>> in the #terminate method of Process and the VM hangs there. >>>>>>>>>>>>> >>>>>>>>>>>>> I believe they had ProbabilityDistribution subclass from Stream >>>>>>>>>>>>> because sampling from a distribution is like reading from a >>>>>>>>>>>>> Stream, but I >>>>>>>>>>>>> don't think any there's any actual shared code, so I switched the >>>>>>>>>>>>> superclass >>>>>>>>>>>>> of ProbabilityDistribution to Object and the code works fine now. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks. >>>>>>>>>>>>> >>>>>>>>>>>>> Larry >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> -- >>>> Marcus Denker -- [email protected] >>>> http://www.marcusdenker.de >>>> > <Fix-Error-description.st>
