October 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] startup errors

by Schwab,Wilhelm K

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: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Tuesday, October 25, 2011 9:40 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] startup errors On 24 October 2011 11:40, Andrea BrÃ¼hlmann <a.bruehlmann(a)netstyle.ch> 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.

Oct. 25, 2011

Re: [Pharo-project] Correct usage of exception handlers with ensure and ifCurtailed

by John Toohey

- Yes it quits, not aborts. The issue is that the WAListenerAdapter throws ConnectionTimedOut exceptions, and in the headless state, these un-handled exceptions cause the VM to shutdown. My Seaside app has a custom Exception handler registered for the app, but its not called here. This code is from the WAListenerAdapter, so all I want to do is catch the exception and ignore it. Sockets timing out in a web app is not an exception. The stack trace runs from the Socket class back to the WAListenerAdapter class, so that is why I wanted to put a handler there. The code is the original code from that class. In the context of my web app, a socket timing out is not exceptional, so all I want to for the code to clean up after itself, and accept back on the socket. I was hoping that the handler that I put it would be sufficient, but your comments on the background process it making me wonder. On Tue, Oct 25, 2011 at 14:04, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Mon, Oct 24, 2011 at 9:13 AM, John Toohey <jt(a)parspro.com> wrote: >> >> Hi, >> I have an issue with WAListenerAdapter throwing ConnectionTimeOut and >> ConnectionClosed exceptions in a headless image, which causes the VM >> to abort. > > I doubt that the VM aborts. Â I expect the headless unhandled exception > handler quits the system. > >> >> These "exceptions" are just socket timeouts, and can be >> ignored. >> >> The methods that I believe is the correct place to handle these is >> coded as follows :- >> >> waitForConnection: aSocket >> Â Â Â Â | socket stream | >> Â Â Â Â socket := aSocket waitForAcceptFor: 10. >> Â Â Â Â socket isNil ifTrue: [ ^ self ]. >> Â Â Â Â stream := SocketStream on: socket. >> Â Â Â Â [ [ [ self process: stream ] >> Â Â Â Â Â Â Â Â ensure: [ stream close ] ] >> Â Â Â Â Â Â Â Â Â Â Â Â ifCurtailed: [ socket destroy ] ] >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â forkAt: Processor userBackgroundPriority >> >> I've changed the code so it looks like this :- >> >> waitForConnection: aSocket >> Â Â Â Â | socket stream | >> Â Â Â Â socket := aSocket waitForAcceptFor: 10. >> Â Â Â Â socket isNil ifTrue: [ ^ self ]. >> Â Â Â Â stream := SocketStream on: socket. >> Â Â Â Â [ [ [ [self process: stream ] >> Â Â Â Â Â Â Â Â on: NetworkError >> Â Â Â Â Â Â Â Â do:[:ex| ^self]] >> Â Â Â Â Â Â Â Â ensure: [ stream close ] ] >> Â Â Â Â Â Â Â Â Â Â Â Â ifCurtailed: [ socket destroy ] ] >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â forkAt: Processor userBackgroundPriority >> >> As the errors are intermittent and only occur on my production server, >> I wonder is someone can look at the code, and tell me if I've added >> the #on:do: block correctly. > > What is the error that is raised? Â You should see some info in > SqueakDebug.log or some such. Â Also I think tat using userBackgroundPriority > here as I suspect as it would conflict with the background process. Â I would > use userBackgroundPriority Â 1. Â However, if process: passes on the socket to > some other process and the error is raised in the context of that process > then your exception handler in your background process isn't going to handle > it. > Some things to try: > - examine the backtrace in SqueakDebug.log (and if you don't get one look at > the system's headless error handler and make sure it gives you a back > trace). > - last resort, run the VM in gdb, put a breakpoint in e.g. exit and then > call printCallStack() or printAllStacks() to see what's going on at the > point of exit. > HTH >> >> Thanks. >> -- >> ~JT >> > > > > -- > best, > Eliot > -- ~JT

Oct. 25, 2011

Re: [Pharo-project] Text for 1.3 announcement?

by Bernhard Pieber

May I humbly suggest to at least add a link to known open issues for 1.3 right next to the release download? Then at least a newbie knows what to expect. Thanks for all your effort! Cheers, Bernhard Am 21.10.2011 um 15:24 schrieb Marcus Denker: > On Oct 21, 2011, at 3:17 PM, Igor Stasenko wrote: > On 21 October 2011 13:59, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>> I am concerned about the error handling failure that I (easily) encountered, at least on Linux. Has anyone tried to reproduce it? >> How does that prevent from releasing 1.3? >> >> If there are obscure bugs, they will be fixed in 1.4. > > Or even in 1.3... (just added 3 fixes today). > > The thing is that there are indefinit unknown problems. If we wait a week, for sure someone finds another. > > "Release" does not mean "Bug free", because "bug free" does not exist. > (and it is even harder in a system with a huge, historical code base and an undefined feature set... I am > always amazed to learn new features that people seem to not be able to life without that I did not even > know existed. How can we gurantee that these don't break? We just can't). > > Marcus

Oct. 25, 2011

Re: [Pharo-project] Correct usage of exception handlers with ensure and ifCurtailed

by Eliot Miranda

On Mon, Oct 24, 2011 at 9:13 AM, John Toohey <jt(a)parspro.com> wrote: > Hi, > I have an issue with WAListenerAdapter throwing ConnectionTimeOut and > ConnectionClosed exceptions in a headless image, which causes the VM > to abort. I doubt that the VM aborts. I expect the headless unhandled exception handler quits the system. > These "exceptions" are just socket timeouts, and can be > ignored. > > The methods that I believe is the correct place to handle these is > coded as follows :- > > waitForConnection: aSocket > | socket stream | > socket := aSocket waitForAcceptFor: 10. > socket isNil ifTrue: [ ^ self ]. > stream := SocketStream on: socket. > [ [ [ self process: stream ] > ensure: [ stream close ] ] > ifCurtailed: [ socket destroy ] ] > forkAt: Processor userBackgroundPriority > > I've changed the code so it looks like this :- > > waitForConnection: aSocket > | socket stream | > socket := aSocket waitForAcceptFor: 10. > socket isNil ifTrue: [ ^ self ]. > stream := SocketStream on: socket. > [ [ [ [self process: stream ] > on: NetworkError > do:[:ex| ^self]] > ensure: [ stream close ] ] > ifCurtailed: [ socket destroy ] ] > forkAt: Processor userBackgroundPriority > > As the errors are intermittent and only occur on my production server, > I wonder is someone can look at the code, and tell me if I've added > the #on:do: block correctly. > What is the error that is raised? You should see some info in SqueakDebug.log or some such. Also I think tat using userBackgroundPriority here as I suspect as it would conflict with the background process. I would use userBackgroundPriority 1. However, if process: passes on the socket to some other process and the error is raised in the context of that process then your exception handler in your background process isn't going to handle it. Some things to try: - examine the backtrace in SqueakDebug.log (and if you don't get one look at the system's headless error handler and make sure it gives you a back trace). - last resort, run the VM in gdb, put a breakpoint in e.g. exit and then call printCallStack() or printAllStacks() to see what's going on at the point of exit. HTH > Thanks. > -- > ~JT > > -- best, Eliot

Oct. 25, 2011

Re: [Pharo-project] How to encrypt a password?

by mkobetic＠gmail.com

"Milan Mimica"<milan.mimica(a)gmail.com> wrote: > To make it slightly more secure, you can put a little salt in it: > > salt := 'Some random string I just cam up with 123' > > password:= SecureHashAlgorithm new hashMessage: salt, aClearTextPass. > > check: > password = SecureHashAlgorithm new hashMessage: salt, aPasswordAttempt. > > That way you make it more difficult for the attacker to brute-force guess > the password when the user supplies a weak password. Note though that if the intent is to hardcode the hash (and presumably the salt as well) in the code it kinda defeats the purpose of the salt. Salt doesn't need to be secret, but it should be sufficiently unpredictable, so that the attacker cannot pre-compute the hashes easily. If the salt is fixed and well known, then it doesn't help. I guess my main point is that hardcoding the password in any shape or form is nearly useless, you may as well not bother. What is the goal ? What are you trying to protect against ? Answers to these questions should guide you to a solution. Once you pick a solution you should then think about how it fails and what can you do when it happens (What will you do when your hardcoded password becomes compromised ?). False security is often worse than no security. HTH, Martin

Oct. 25, 2011

Re: [Pharo-project] How to encrypt a password?

by Alexandre Bergel

Thanks for your answers, I am learning. Alexandre On 25 Oct 2011, at 03:40, Milan Mimica wrote: > On 25 October 2011 04:43, mail list <mail.list(a)ficonab.com> wrote: > Someone may have already replied as I am writing this on a plane but generally for passwords you do not write a decrypt method for security purposes (eg you do not want people to be able to reverse engineer the encrypted password easily) > > You just compare encrypted passwords to see if they are equal. > eg > password:= SecureHashAlgorithm new hashMessage: aClearTextPass. > > then later on you check > password = SecureHashAlgorithm new hashMessage: aPasswordAttempt. > > > To make it slightly more secure, you can put a little salt in it: > > salt := 'Some random string I just cam up with 123' > > password:= SecureHashAlgorithm new hashMessage: salt, aClearTextPass. > > check: > password = SecureHashAlgorithm new hashMessage: salt, aPasswordAttempt. > > That way you make it more difficult for the attacker to brute-force guess the password when the user supplies a weak password. > > > -- > Milan Mimica > http://sparklet.sf.net -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 25, 2011

Re: [Pharo-project] Having a shared package-cache Re: MCDirectoryRepository defaultDirectoryName ignored?

by StÃ©phane Ducasse

yes publish it somewhere. On Oct 24, 2011, at 1:07 PM, Mariano Martinez Peck wrote: > > > On Sun, Oct 23, 2011 at 11:13 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > I am not sure if it is the best solution, but it works, an that's all I need :) > What I did is to implement two extension methods: > > MCCachedRepository >> marianoDefaultWithDirectory: aDirectory > self checkCacheDirectory. > ^ default ifNil: [default := self new directory: aDirectory] > > MCCachedRepository >> marianoReset > default := nil. > > > Maybe this is helpful for other guys as well? In such case, I can commit: > > MCCachedRepository >> changeDefaultWithDirectory: aDirectory > default := nil. > ^ default ifNil: [default := self new directory: aDirectory] > > What do you think? > > Cheers > > > And then in my build script I execute: > > MCCacheRepository marianoReset. > MCCacheRepository marianoDefaultWithDirectory: self sharedPackageCacheDirectory. > > >> sharedPackageCacheDirectory > (FileDirectory on: self sharedPackageCacheName) > assureExistence; > yourself > > >> sharedPackageCacheName > ^ '/Users/mariano/Pharo/localRepo/' > > > Cheers > > > On Sun, Oct 23, 2011 at 10:51 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > how? > > Stef > > On Oct 21, 2011, at 11:26 PM, Mariano Martinez Peck wrote: > > > Thanks guys. I was able to successfully change the directory of the package-cache. > > > > On Fri, Oct 21, 2011 at 12:15 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > > You could add startup code that resets it to an absolute fixed location. > > > > I would go with the links. > > > > Lukas > > > > On 21 October 2011 11:59, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > > > > > On 21 Oct 2011, at 11:47, Mariano Martinez Peck wrote: > > > > > >> Hi guys. I would really LOVE to have a shared package-cache among images. I have (really) 1 gb of .mcz in different package-cache. > > >> I am using new images all the time (hence package cache is empty). I would love to be able to reuse the same package-cache directory for all my images. > > >> So...how can I change the place where the package-cache is created so that it uses another directory? > > > > > > Mine is 0.75 GB, but shared: I put all my images in the same directory. > > > Working with links is also an option, I think that is what Lukas' build scripts do. > > > > > > Sven > > > > > > > > > > > > > > > > > -- > > Lukas Renggli > > www.lukas-renggli.ch > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Oct. 25, 2011

Re: [Pharo-project] UI blocked

by StÃ©phane Ducasse

excellent! I just time... Stef > We will have to have a look at this event stuff. >> Probably beginning of the year. > > Super, thanks Stef and Igor! I also prepared hooks and a backdoor script > execution via web, so that we can investigate the image even if input is > blocked. So next time this will happen, you can inspect and debug my > image even from your machine :) > > Best regards > Janko > > >> >> Stef >> >> On Oct 23, 2011, at 7:36 PM, Janko MivÅ¡ek wrote: >> >>> Hi guys, >>> >>> My 1.3 #13299 image is blocked again, but just UI not responding to any >>> input events, while Aida web app server is running smoothly in backrgound. >>> >>> From Transcript I can see that last action was a new image backup >>> procedure, which is done simply by : >>> >>> OSProcess waitForCommand: 'cp some.image some-bck.image'. >>> >>> This procedure is called from a background process and report to >>> Transcript its start and end. Is there something wrong with that? Or is >>> some interference with OSProcess semaphores? (I saw such suspicious >>> thing once before). >>> >>> In any case, is there a way to unblock image now? Ctrl or Alt . doesn't >>> help. >>> >>> Best regards >>> Janko >>> >>> -- >>> Janko MivÅ¡ek >>> Aida/Web >>> Smalltalk Web Application Server >>> http://www.aidaweb.si >>> >> >> >> > > -- > Janko MivÅ¡ek > Svetovalec za informatiko > Eranova d.o.o. > Ljubljana, Slovenija > www.eranova.si > tel: 01 514 22 55 > faks: 01 514 22 56 > gsm: 031 674 565 >

Oct. 25, 2011

Re: [Pharo-project] Jenkis small delay possible?

by Yanni Chiu

On 25/10/11 3:43 AM, Norbert Hartl wrote: > > No, the simplest is to leave it as it is. Do you really think it is worth the effort? A new repo and pseudo configuration commits just to prevent a few bogus "jenkins became unstable" mails? What is the problem with it? If you know that it can happen you can just look at it that way. In this particular case there is not only a broken build but also a new build in the queue. If you just develop the habbit to look after the last build you will see there is no problem. > I have plenty of experience how this "clever tweaking" of the configuration management tools has the potential to make it really worse. Even the raise of the delay will get on someones nerves that tries to fix a configuration. That will lead to have to do a lot of builds until it works. For this use case the 5 minutes delay is already unbearable, etc. I agree - adjust to look for a new build in the queue. But, you have to wait for 2 or 5 minutes (minus build time) before the new build appears. A long while back, I used to have builds occasionally fail (unexpectedly?). The first two times I dug in, and debugged the test failure to find a code inconsistency. Then I looked at the repository to find that there was a newer version with a very recent timestamp (i.e. a difference of about the time I'd spent debugging). Eventually, I learned that if the build failure was not due to my code, I did not debug it first thing. Instead, I started a new build. One way to shorten the commit time is to commit to a local repository, then upload to squeaksource. That leaves time to browse changes and think about the commit comments.

Oct. 25, 2011

Re: [Pharo-project] UI blocked

by Nevin Pratt

On 10/23/11 11:36 AM, Janko MivÅ¡ek wrote: > Hi guys, > > My 1.3 #13299 image is blocked again, but just UI not responding to any > input events, while Aida web app server is running smoothly in backrgound. > > > From Transcript I can see that last action was a new image backup > procedure, which is done simply by : > > OSProcess waitForCommand: 'cp some.image some-bck.image'. > > This procedure is called from a background process and report to > Transcript its start and end. Is there something wrong with that? Or is > some interference with OSProcess semaphores? (I saw such suspicious > thing once before). > > In any case, is there a way to unblock image now? Ctrl or Alt . doesn't > help. > > Best regards > Janko > For what it's worth, the UI blocking also happens occasionally (not very often, but occasionally) with Squeak 3.8/Seaside 2.8. But it's easy to unblock. Just run the "screenshot" app (within Seaside), then at the top there is a "Suspend UI Process" link. Click it to suspend, then click it again to unsuspend. That almost always unblocks the UI, although occasionally I have to suspend and unsuspend a second time, not just once. But, because of the "screenshot" app is able to unblock it, the UI blocking problem has never been more than a minor inconvenience. Nevin

Oct. 25, 2011