[Pharo-project] Monticello/ftp stopped working for me
So it is rather funny that after commenting on how I have been using Monticello's FTP repository feature all along (since December)... it stopped working on me yesterday after an update. My starting image was pharo0.1-10268web09.04.1 and I did an update yesterday, and I saw my first failure of Monticello last night, and now again this morning (and I just loaded something from the inbox). So a problem was fairly recently introduced, and I am in a position to help debug this. How do I find out what all updates were installed recently? Thanks in advance, Cam
What do yo mean stop working? I am in the same situation than Stéphane, I get a 'Socket status must Unconnected before opening a new connection' error when doing a ScriptLoader loadOBAlpha Alexandre On 28 Apr 2009, at 15:33, Cameron Sanders wrote:
So it is rather funny that after commenting on how I have been using Monticello's FTP repository feature all along (since December)... it stopped working on me yesterday after an update.
My starting image was pharo0.1-10268web09.04.1 and I did an update yesterday, and I saw my first failure of Monticello last night, and now again this morning (and I just loaded something from the inbox).
So a problem was fairly recently introduced, and I am in a position to help debug this.
How do I find out what all updates were installed recently?
Thanks in advance, Cam
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
This is the first time it has failed for me. I have been using MCs FTP in a variety of different images & VMs over the last four months. Suddenly... MessageNotUnderstood: ByteArray>>port: in Socket>>connectTo:port:. Previously, hostAddress (in the aforementioned method) had been a SocketAddress, but now it is a ByteArray. See http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg07986.htm... . How do I see which updates were installed in the last 24 hours? Oh... looks like a lot based on the cache. (or were those just touched?) -Cam On Apr 28, 2009, at 9:35 AM, Alexandre Bergel wrote:
What do yo mean stop working? I am in the same situation than Stéphane, I get a 'Socket status must Unconnected before opening a new connection' error when doing a ScriptLoader loadOBAlpha
Alexandre
On 28 Apr 2009, at 15:33, Cameron Sanders wrote:
So it is rather funny that after commenting on how I have been using Monticello's FTP repository feature all along (since December)... it stopped working on me yesterday after an update.
My starting image was pharo0.1-10268web09.04.1 and I did an update yesterday, and I saw my first failure of Monticello last night, and now again this morning (and I just loaded something from the inbox).
So a problem was fairly recently introduced, and I am in a position to help debug this.
How do I find out what all updates were installed recently?
Thanks in advance, Cam
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I have a different error. Regarding updates, you can have a look at the package-cache, but printIt 'ScriptLoader new logStream' should do what you want Cheers, Alexandre On 28 Apr 2009, at 16:16, Cameron Sanders wrote:
This is the first time it has failed for me. I have been using MCs FTP in a variety of different images & VMs over the last four months. Suddenly...
MessageNotUnderstood: ByteArray>>port:
in Socket>>connectTo:port:.
Previously, hostAddress (in the aforementioned method) had been a SocketAddress, but now it is a ByteArray.
See http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg07986.htm... .
How do I see which updates were installed in the last 24 hours? Oh... looks like a lot based on the cache. (or were those just touched?)
-Cam
On Apr 28, 2009, at 9:35 AM, Alexandre Bergel wrote:
What do yo mean stop working? I am in the same situation than Stéphane, I get a 'Socket status must Unconnected before opening a new connection' error when doing a ScriptLoader loadOBAlpha
Alexandre
On 28 Apr 2009, at 15:33, Cameron Sanders wrote:
So it is rather funny that after commenting on how I have been using Monticello's FTP repository feature all along (since December)... it stopped working on me yesterday after an update.
My starting image was pharo0.1-10268web09.04.1 and I did an update yesterday, and I saw my first failure of Monticello last night, and now again this morning (and I just loaded something from the inbox).
So a problem was fairly recently introduced, and I am in a position to help debug this.
How do I find out what all updates were installed recently?
Thanks in advance, Cam
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Thanks Alexandre. So to get my MC-ftp connection working (to save code changes in my image), I simply masked the problem. I altered NetNameResolver class >> useOldNetwork to simply return true. The preparation of the class variable UseOldNetwork looks like the following in the method NetNameResolver class>>initializeNetwork ... UseOldNetwork := [NetNameResolver primHostNameSize. false] on: Error do: [:ex | ex return: true] And #primHostNameSize is failing under older versions; the code is NetNameResolver class >> primHostNameSize <primitive: 'primitiveResolverHostNameSize' module: 'SocketPlugin'> self primitiveFailed -- I haven't been following the socket/FFI stuff, but this was just fixed, right? And the "owner" (or lead) is who? -Cam
I was also trying to track down the problem. The log on Squeaksource says: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Name: Network-Kernel-stephane_ducasse.6 Author: stephane.ducasse Time: 30 March 2009, 11:21:24 pm UUID: cb7829c0-0006-4b44-ad73-ab97531bc8ce Ancestors: Network-Kernel-michael_rueger.5 Issue 648: Opening protocol browser results in a MessageNotUnderstood: CompiledMethod>>category CompiledMethod>>category by eric Issue 684: Recent Morphic Changesets Removed BorderedMorph>>areasRemainingToFill: Issue 691: integrate Setting System-Setting Issue 696: SuniGUi showing coverage SUnit coverage enhancement Issue 697: New Socket IPv6 new socket primitive and IPv6 changes -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= The new socket is likely to be the culprit. Unfortunately, the google website does not say much: http://code.google.com/p/pharo/issues/detail?can=2&q=697&colspec=ID%20Type%2... I am trying your trick. Alexandre On 28 Apr 2009, at 19:10, Cameron Sanders wrote:
Thanks Alexandre.
So to get my MC-ftp connection working (to save code changes in my image), I simply masked the problem. I altered NetNameResolver class >> useOldNetwork to simply return true.
The preparation of the class variable UseOldNetwork looks like the following in the method NetNameResolver class>>initializeNetwork ... UseOldNetwork := [NetNameResolver primHostNameSize. false] on: Error do: [:ex | ex return: true]
And #primHostNameSize is failing under older versions; the code is
NetNameResolver class >> primHostNameSize <primitive: 'primitiveResolverHostNameSize' module: 'SocketPlugin'> self primitiveFailed -- I haven't been following the socket/FFI stuff, but this was just fixed, right? And the "owner" (or lead) is who?
-Cam
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hum... "ScriptLoader loadOBAlpha" still does not pass... Alexandre On 28 Apr 2009, at 19:10, Cameron Sanders wrote:
Thanks Alexandre.
So to get my MC-ftp connection working (to save code changes in my image), I simply masked the problem. I altered NetNameResolver class >> useOldNetwork to simply return true.
The preparation of the class variable UseOldNetwork looks like the following in the method NetNameResolver class>>initializeNetwork ... UseOldNetwork := [NetNameResolver primHostNameSize. false] on: Error do: [:ex | ex return: true]
And #primHostNameSize is failing under older versions; the code is
NetNameResolver class >> primHostNameSize <primitive: 'primitiveResolverHostNameSize' module: 'SocketPlugin'> self primitiveFailed -- I haven't been following the socket/FFI stuff, but this was just fixed, right? And the "owner" (or lead) is who?
-Cam
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I am not sure to understand. I would like to be able to load OBAlpha in Pharo and to not have this the socket problem. Cheers, Alexandre On 28 Apr 2009, at 21:30, Cameron Sanders wrote:
Alexandre,
Is your interest in getting the unit-test to pass, or o be able to use it?
-Cam
On Apr 28, 2009, at 1:35 PM, Alexandre Bergel wrote:
Hum... "ScriptLoader loadOBAlpha" still does not pass...
Alexandre
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
So you want to use the MC/FTP feature. You are not testing it to make certain that the MC/FTP works. What is is your server string? -Cam
Maybe it is still a bit early in the morning, but I am not sure to understand what you mean with "MC/FTP feature". What am I not testing? Alexandre On 29 Apr 2009, at 03:39, Cameron Sanders wrote:
So you want to use the MC/FTP feature. You are not testing it to make certain that the MC/FTP works.
What is is your server string?
-Cam
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Alexandre Bergel wrote:
Maybe it is still a bit early in the morning, but I am not sure to understand what you mean with "MC/FTP feature". What am I not testing?
You two are talking about two different bugs. Alexandre, you are most likely using a HTTP based repository, so you are not testing the MC FTP backend. Also, the error in the FTP backend is different than for the HTTP one. Michael
Probably, I have never used the ftp backend. However, maybe this is the same bug, rooted in Socket. I will spend some time this morning on this. Alexandre On 29 Apr 2009, at 09:41, Michael Rueger wrote:
Alexandre Bergel wrote:
Maybe it is still a bit early in the morning, but I am not sure to understand what you mean with "MC/FTP feature". What am I not testing?
You two are talking about two different bugs. Alexandre, you are most likely using a HTTP based repository, so you are not testing the MC FTP backend. Also, the error in the FTP backend is different than for the HTTP one.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Alexandre, I assume you are also following the threads on squeak-dev regarding "[squeak-dev] Re: Socket clock rollover issues" -- is the problem you are investigating related to that issue (e.g. failure due to a time- out)? Are you connecting to a public repository? If so, give me the info (to setup the repository) and I will try it. Cheers, Cam On Apr 29, 2009, at 3:48 AM, Alexandre Bergel wrote:
Probably, I have never used the ftp backend. However, maybe this is the same bug, rooted in Socket. I will spend some time this morning on this.
Alexandre
On 29 Apr 2009, at 09:41, Michael Rueger wrote:
Alexandre Bergel wrote:
Maybe it is still a bit early in the morning, but I am not sure to understand what you mean with "MC/FTP feature". What am I not testing?
You two are talking about two different bugs. Alexandre, you are most likely using a HTTP based repository, so you are not testing the MC FTP backend. Also, the error in the FTP backend is different than for the HTTP one.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
This is very unlikelya rollover: rollover happens once every 12 days or so. Nicolas 2009/4/29 Cameron Sanders <camsanders01@roadrunner.com>:
Alexandre, I assume you are also following the threads on squeak-dev regarding "[squeak-dev] Re: Socket clock rollover issues" -- is the problem you are investigating related to that issue (e.g. failure due to a time-out)? Are you connecting to a public repository? If so, give me the info (to setup the repository) and I will try it. Cheers, Cam
On Apr 29, 2009, at 3:48 AM, Alexandre Bergel wrote:
Probably, I have never used the ftp backend. However, maybe this is the same bug, rooted in Socket. I will spend some time this morning on this.
Alexandre
On 29 Apr 2009, at 09:41, Michael Rueger wrote:
Alexandre Bergel wrote:
Maybe it is still a bit early in the morning, but I am not sure to
understand what you mean with "MC/FTP feature". What am I not
testing?
You two are talking about two different bugs.
Alexandre, you are most likely using a HTTP based repository, so you
are
not testing the MC FTP backend. Also, the error in the FTP backend is
different than for the HTTP one.
Michael
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel  http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Very good -- i have not followed it closely. Thank you. -Cam On Apr 29, 2009, at 11:38 AM, Nicolas Cellier wrote:
This is very unlikelya rollover: rollover happens once every 12 days or so.
Nicolas
2009/4/29 Cameron Sanders <camsanders01@roadrunner.com>:
Alexandre, I assume you are also following the threads on squeak-dev regarding "[squeak-dev] Re: Socket clock rollover issues" -- is the problem you are investigating related to that issue (e.g. failure due to a time-out)? Are you connecting to a public repository? If so, give me the info (to setup the repository) and I will try it. Cheers, Cam
On Apr 29, 2009, at 3:48 AM, Alexandre Bergel wrote:
Probably, I have never used the ftp backend. However, maybe this is the same bug, rooted in Socket. I will spend some time this morning on this.
Alexandre
On 29 Apr 2009, at 09:41, Michael Rueger wrote:
Alexandre Bergel wrote:
Maybe it is still a bit early in the morning, but I am not sure to
understand what you mean with "MC/FTP feature". What am I not
testing?
You two are talking about two different bugs.
Alexandre, you are most likely using a HTTP based repository, so you
are
not testing the MC FTP backend. Also, the error in the FTP backend is
different than for the HTTP one.
Michael
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Open a Pharo image, and execute "ScriptLoader loadOBAlpha" If you have a Mac, this will surely fail. Alexandre On 29 Apr 2009, at 17:32, Cameron Sanders wrote:
Alexandre, I assume you are also following the threads on squeak-dev regarding "[squeak-dev] Re: Socket clock rollover issues" -- is the problem you are investigating related to that issue (e.g. failure due to a time-out)?
Are you connecting to a public repository? If so, give me the info (to setup the repository) and I will try it.
Cheers, Cam
On Apr 29, 2009, at 3:48 AM, Alexandre Bergel wrote:
Probably, I have never used the ftp backend. However, maybe this is the same bug, rooted in Socket. I will spend some time this morning on this.
Alexandre
On 29 Apr 2009, at 09:41, Michael Rueger wrote:
Alexandre Bergel wrote:
Maybe it is still a bit early in the morning, but I am not sure to understand what you mean with "MC/FTP feature". What am I not testing?
You two are talking about two different bugs. Alexandre, you are most likely using a HTTP based repository, so you are not testing the MC FTP backend. Also, the error in the FTP backend is different than for the HTTP one.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I confirm it works on windows and fails on linux (exupery VM) Nicolas 2009/4/29 Alexandre Bergel <alexandre@bergel.eu>:
Open a Pharo image, and execute "ScriptLoader loadOBAlpha" If you have a Mac, this will surely fail.
Alexandre
On 29 Apr 2009, at 17:32, Cameron Sanders wrote:
Alexandre, I assume you are also following the threads on squeak-dev regarding "[squeak-dev] Re: Socket clock rollover issues" -- is the problem you are investigating related to that issue (e.g. failure due to a time-out)?
Are you connecting to a public repository? If so, give me the info (to setup the repository) and I will try it.
Cheers, Cam
On Apr 29, 2009, at 3:48 AM, Alexandre Bergel wrote:
Probably, I have never used the ftp backend. However, maybe this is the same bug, rooted in Socket. I will spend some time this morning on this.
Alexandre
On 29 Apr 2009, at 09:41, Michael Rueger wrote:
Alexandre Bergel wrote:
Maybe it is still a bit early in the morning, but I am not sure to understand what you mean with "MC/FTP feature". What am I not testing?
You two are talking about two different bugs. Alexandre, you are most likely using a HTTP based repository, so you are not testing the MC FTP backend. Also, the error in the FTP backend is different than for the HTTP one.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Also note that it fails at the end of the progress bar. And inspecting response tempVar in HTTPSocket>>getRestOfBuffer: leads to: collection copyFrom: readLimit-100 to: readLimit -> 'Standard.39-cwp.1.mcz</a> 18-Aug-2006 19:38 50K <hr></pre> </body></html> ' I don't want to learn anything about http protocol, but it sounds like the whole stream was correctly retrieved. That means something has changed in the order things are processed. We should test if it is a matter of VM or in image change. Nicolas 2009/4/29 Michael Rueger <m.rueger@acm.org>:
Nicolas Cellier wrote:
I confirm it works on windows and fails on linux (exupery VM)
as it also fails on Mac it seems it could be the Unix socket code?
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
OK guys, I think you loaded my rollover stuff... Mea maxima culpa: #waitForDataUntil: and #waitForDataFor: DID NOT DO THE SAME THING! the former signals ConnectionClosed, while the later silently answer false... The reason it works on windws is probably I did not load my change (I used a different image...). Strangely, I used Monticello on squeaksource without encountering this bug... Nicolas 2009/4/29 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
Also note that it fails at the end of the progress bar. And inspecting response tempVar in HTTPSocket>>getRestOfBuffer: leads to:
collection copyFrom: readLimit-100 to: readLimit -> 'Standard.39-cwp.1.mcz</a> 18-Aug-2006 19:38 50K <hr></pre> </body></html> '
I don't want to learn anything about http protocol, but it sounds like the whole stream was correctly retrieved. That means something has changed in the order things are processed. We should test if it is a matter of VM or in image change.
Nicolas
2009/4/29 Michael Rueger <m.rueger@acm.org>:
Nicolas Cellier wrote:
I confirm it works on windows and fails on linux (exupery VM)
as it also fails on Mac it seems it could be the Unix socket code?
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Could you test if this fix works: PharoInbox/SLICE-M7343-Socket-Rollover-bug-nice.2 2009/4/29 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
OK guys, I think you loaded my rollover stuff... Mea maxima culpa:
#waitForDataUntil: and #waitForDataFor: DID NOT DO THE SAME THING!
the former signals ConnectionClosed, while the later silently answer false...
The reason it works on windws is probably I did not load my change (I used a different image...).
Strangely, I used Monticello on squeaksource without encountering this bug...
Nicolas
2009/4/29 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
Also note that it fails at the end of the progress bar. And inspecting response tempVar in HTTPSocket>>getRestOfBuffer: leads to:
collection copyFrom: readLimit-100 to: readLimit -> 'Standard.39-cwp.1.mcz</a> 18-Aug-2006 19:38 50K <hr></pre> </body></html> '
I don't want to learn anything about http protocol, but it sounds like the whole stream was correctly retrieved. That means something has changed in the order things are processed. We should test if it is a matter of VM or in image change.
Nicolas
2009/4/29 Michael Rueger <m.rueger@acm.org>:
Nicolas Cellier wrote:
I confirm it works on windows and fails on linux (exupery VM)
as it also fails on Mac it seems it could be the Unix socket code?
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Does not work for me. The problem is probably different. I still get a 'Socket status must Unconnected before opening a new connection' Alexandre On 29 Apr 2009, at 21:39, Nicolas Cellier wrote:
Could you test if this fix works:
PharoInbox/SLICE-M7343-Socket-Rollover-bug-nice.2
2009/4/29 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
OK guys, I think you loaded my rollover stuff... Mea maxima culpa:
#waitForDataUntil: and #waitForDataFor: DID NOT DO THE SAME THING!
the former signals ConnectionClosed, while the later silently answer false...
The reason it works on windws is probably I did not load my change (I used a different image...).
Strangely, I used Monticello on squeaksource without encountering this bug...
Nicolas
2009/4/29 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
Also note that it fails at the end of the progress bar. And inspecting response tempVar in HTTPSocket>>getRestOfBuffer: leads to:
collection copyFrom: readLimit-100 to: readLimit -> 'Standard.39-cwp.1.mcz</a> 18-Aug-2006 19:38 50K <hr></pre> </body></html> '
I don't want to learn anything about http protocol, but it sounds like the whole stream was correctly retrieved. That means something has changed in the order things are processed. We should test if it is a matter of VM or in image change.
Nicolas
2009/4/29 Michael Rueger <m.rueger@acm.org>:
Nicolas Cellier wrote:
I confirm it works on windows and fails on linux (exupery VM)
as it also fails on Mac it seems it could be the Unix socket code?
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Maybe I'm just sleep deprived... but, the method isUnconnected looks odd. Perhaps it is correct, and there is a good reason for the implementation, but "socketHandle == nil ifTrue: [^false ]" seems counter-intuitive. If socketHandle is not defined, then, it seems, we probably not connected... and hence should answer true. My apologies if I am not thinking clearly... or if it is simply more complex handle management. Socket >> isUnconnected "Return true if this socket's state is Unconnected." socketHandle == nil ifTrue: [^ false]. ^ (self primSocketConnectionStatus: socketHandle) == Unconnected -Cam On Apr 29, 2009, at 5:00 PM, Alexandre Bergel wrote:
Does not work for me. The problem is probably different. I still get a 'Socket status must Unconnected before opening a new connection'
Per
Don't worry, I "get it" from the logical view. I just wondered if it was related to 'Socket status must Unconnected before opening a new connection'. -cam On Apr 29, 2009, at 10:27 PM, Cameron Sanders wrote:
Maybe I'm just sleep deprived... but, the method isUnconnected looks odd. Perhaps it is correct, and there is a good reason for the implementation, but "socketHandle == nil ifTrue: [^false ]" seems counter-intuitive. If socketHandle is not defined, then, it seems, we probably not connected... and hence should answer true.
My apologies if I am not thinking clearly... or if it is simply more complex handle management.
Socket >> isUnconnected "Return true if this socket's state is Unconnected."
socketHandle == nil ifTrue: [^ false]. ^ (self primSocketConnectionStatus: socketHandle) == Unconnected
-Cam
On Apr 29, 2009, at 5:00 PM, Alexandre Bergel wrote:
Does not work for me. The problem is probably different. I still get a 'Socket status must Unconnected before opening a new connection'
Per
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Er maybe someone doing the testing can stick a Socket allInstances size inspect in at the pointer where the exception is signaled. I think it would be enlightening what the value is. On 29-Apr-09, at 7:52 PM, Cameron Sanders wrote:
Socket status must Unconnected before opening a new connection
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
Further to this I"m wondering if there is something else "clever" going on. Should the finalization process run at priority 61? See WeakArray>>restartFinalizationProcess Perhaps someone can check that? Let me ramble on... In the past you had the event polling going on at prioirty 40 in the 'UI process' That would grind away... You also had the 'event tickler' that ran every 500 ms at priority 60. And there in the middle why the key player here, the 'WeakArray finalization process' at 50 In this problem area, if we consider the socket creation fails because the number of sockets allocated has reached the limit (aka unix limit) not seen in windows. then this is because either (a) we are actualy holding onto thousands of sockets on purpose? Or we have 1, and thousands of zombies that have been tenured to OldSpace but not yet GCed, and Unix is unhappy with us. Now when the socket create fails that causes well another pointless attempt at creation (why?) but also a full GC. The full GC will of course signal to the 'WeakArray finalization process' for it to gently destroy sockets. But let's consider what's NEW here is the 'input events fetching process' is now running at 2x the speed of the older UI process and consuming 10-30% of the cpu? I'm not sure why before it was acceptable to look every 1/50 second, but now it has to be every 1/100 of a second. But it's interesting that it''s running at priority 60, which means it's sucking CPU away from the weak array finalization process. Now as we know the weak array finalization process is rather cpu intensive, so I wonder if there is just enough CPU taken away from finalization process so that it can't do enough work before the retry for the socket allocation leaps in and fails for a final time? Well of course I'm not sure why the finalization process wouldn't finalize all the zombie sockets in one go when the full gc completes, but that would require some more testing... On 29-Apr-09, at 8:09 PM, John M McIntosh wrote:
Er maybe someone doing the testing can stick a Socket allInstances size inspect in at the pointer where the exception is signaled. I think it would be enlightening what the value is.
On 29-Apr-09, at 7:52 PM, Cameron Sanders wrote:
Socket status must Unconnected before opening a new connection
-- = = = = = ====================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
Where do I reduce that priority? -cam On Apr 29, 2009, at 11:40 PM, John M McIntosh wrote:
But let's consider what's NEW here is the 'input events fetching process' is now running at 2x the speed of the older UI process and consuming 10-30% of the cpu? I'm not sure why before it was acceptable to look every 1/50 second, but now it has to be every 1/100 of a second.
But it's interesting that it''s running at priority 60, which means it's sucking CPU away from the weak array finalization process.
On Wed, Apr 29, 2009 at 08:40:37PM -0700, John M McIntosh wrote:
In this problem area, if we consider the socket creation fails because the number of sockets allocated has reached the limit (aka unix limit) not seen in windows. then this is because either (a) we are actualy holding onto thousands of sockets on purpose? Or we have 1, and thousands of zombies that have been tenured to OldSpace but not yet GCed, and Unix is unhappy with us.
I don't know if this is available on OS X, but on some unices (Linux for sure), a good way to check this out is by looking at the open file descriptors listed in the /proc file system. So for example if you have Squeak running in a process with pid 1234, you can see the open file descriptors with "$ ls -l /proc/1234/fd/*".
Now when the socket create fails that causes well another pointless attempt at creation (why?) but also a full GC. The full GC will of course signal to the 'WeakArray finalization process' for it to gently destroy sockets.
And of course relying on finalization to close file/socket handles is a sure-fire way to get into trouble. So if you find lots of open file descriptors in /proc/1234/fd/* that do not correspond to anything being used in the image, then yes you probably do have this kind of issue. On the other hand, if you can see that the number of open file descriptors is well below 1024 (or whatever the limit is on your platform) then the problem lies elsewhere. Dave
I don't know if this is available on OS X, but on some unices (Linux for sure), a good way to check this out is by looking at the open file descriptors listed in the /proc file system. So for example if you have Squeak running in a process with pid 1234, you can see the open file descriptors with "$ ls -l /proc/1234/fd/*".
Nope, no /proc on OS/X, but lsof works here, as on other unices, so continuing your example: lsof|awk '1234==$2{print}' will print info about all open files for process 1234. ../Dave
Well, "Socket allInstances size inspect" is giving me numbers like 8, 6, or 2 from the "ScriptLoader loadOBAlpha" do-it. When I look at the process on the Mac (with the activity monitor), it says I have "Ports: 91". A look at "open files and ports" shows a lengthy list of filenames/devices that are open, but only about 35 show up. There are a few surprises (to me) in the open files list: / -- ?? /Library/Fonts/... -- several of these ... do we really hold the font files open? and /System/Library/Fonts/... ... /usr/lib/dyld /private/var/db/dyld/dyld_shared_cache_i386 /dev/null -- i've been out of C/sys programming for a while (15+ years) and forget why/when we use this -- pipes? ... *:http-alt --- using "lsof | grep Squeak" I get the same list (down below) -- note that I generated this list several times while "ScriptLoader loadOBAlpha" was running, and it added only one line to the output. ---- Squeak 141 sanders cwd DIR 14,2 1156 2 / Squeak 141 sanders txt REG 14,2 2592048 1833085 / Users/sanders/Documents/Pharo-sudoku/Squeak 4.1.0beta1U.app/Contents/ MacOS/Squeak VM Opt Squeak 141 sanders txt REG 14,2 19336 1070045 / private/var/folders/3F/3FmnjhVXHi8w4CG9gjzd7U+++TI/-Caches-/ com.apple.IntlDataCache.le.sbdl Squeak 141 sanders txt REG 14,2 100788 688604 / System/Library/Caches/com.apple.IntlDataCache.le.kbdx Squeak 141 sanders txt REG 14,2 144580 11678 / System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ HIToolbox.framework/Versions/A/Resources/HIToolbox.rsrc Squeak 141 sanders txt REG 14,2 2295501 10702 / System/Library/Fonts/LucidaGrande.dfont Squeak 141 sanders txt REG 14,2 808008 15784 / System/Library/Keyboard Layouts/AppleKeyboardLayouts.bundle/Contents/ Resources/AppleKeyboardLayouts-L.dat Squeak 141 sanders txt REG 14,2 490410 11654 / System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ HIToolbox.framework/Versions/A/Resources/English.lproj/Localized.rsrc Squeak 141 sanders txt REG 14,2 9309920 689553 / private/var/folders/3F/3FmnjhVXHi8w4CG9gjzd7U+++TI/-Caches-/ com.apple.ATS/annex_aux Squeak 141 sanders txt REG 14,2 138848 31052 / Library/Fonts/Trebuchet MS.ttf Squeak 141 sanders txt REG 14,2 129360 31050 / Library/Fonts/Trebuchet MS Bold.ttf Squeak 141 sanders txt REG 14,2 144820 31051 / Library/Fonts/Trebuchet MS Italic.ttf Squeak 141 sanders txt REG 14,2 44848 1833408 / Users/sanders/Documents/Pharo-sudoku/Squeak 4.1.0beta1U.app/Contents/ Resources/SpellingPlugin.bundle/Contents/MacOS/SpellingPlugin Squeak 141 sanders txt REG 14,2 46608 1833402 / Users/sanders/Documents/Pharo-sudoku/Squeak 4.1.0beta1U.app/Contents/ Resources/SpellingPlugin.bundle/Contents/Frameworks/SpellCheck.bundle/ Contents/MacOS/SpellCheck Squeak 141 sanders txt REG 14,2 34952 1833093 / Users/sanders/Documents/Pharo-sudoku/Squeak 4.1.0beta1U.app/Contents/ Resources/ClipboardExtendedPlugin.bundle/Contents/MacOS/ ClipboardExtendedPlugin Squeak 141 sanders txt REG 14,2 137008 31049 / Library/Fonts/Trebuchet MS Bold Italic.ttf Squeak 141 sanders txt REG 14,2 5425538 11671 / System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ HIToolbox.framework/Versions/A/Resources/Extras2.rsrc Squeak 141 sanders txt REG 14,2 946176 1880828 / Library/Caches/com.apple.LaunchServices-023501.csstore Squeak 141 sanders txt REG 14,2 10243824 12079 / usr/share/icu/icudt36l.dat Squeak 141 sanders txt REG 14,2 3537336 1833127 / Users/sanders/Documents/Pharo-sudoku/Squeak 4.1.0beta1U.app/Contents/ Resources/FT2Plugin.bundle/Contents/MacOS/FT2Plugin Squeak 141 sanders txt REG 14,2 1832384 7707 / System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/Resources/ SArtFile.bin Squeak 141 sanders txt REG 14,2 10860368 692208 / System/Library/CoreServices/RawCamera.bundle/Contents/MacOS/RawCamera Squeak 141 sanders txt REG 14,2 5836820 7536 / System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/Resources/ ArtFile.bin Squeak 141 sanders txt REG 14,2 1059792 21872 / usr/lib/dyld Squeak 141 sanders txt REG 14,2 136196096 706084 / private/var/db/dyld/dyld_shared_cache_i386 Squeak 141 sanders 0r CHR 3,2 0t0 119087748 / dev/null Squeak 141 sanders 1 PIPE 0x7232644 16384 Squeak 141 sanders 2 PIPE 0x7232644 16384 Squeak 141 sanders 3r REG 14,2 5425538 11671 / System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ HIToolbox.framework/Versions/A/Resources/Extras2.rsrc Squeak 141 sanders 4r REG 14,2 144580 11678 / System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ HIToolbox.framework/Versions/A/Resources/HIToolbox.rsrc Squeak 141 sanders 5r REG 14,2 490410 11654 / System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ HIToolbox.framework/Versions/A/Resources/English.lproj/Localized.rsrc Squeak 141 sanders 6r DIR 14,2 5814 1102398 / Users/sanders/Documents/Pharo-sudoku/package-cache Squeak 141 sanders 7r REG 14,2 17584742 1102378 / Users/sanders/Documents/Pharo-sudoku/SqueakV39.sources Squeak 141 sanders 8u REG 14,2 32481960 1873656 / Users/sanders/Documents/Pharo-sudoku/pharo0.1-cs-sudoku-1.5.changes Squeak 141 sanders 9u IPv4 0x7c3ce64 0t0 TCP *:http-alt (LISTEN)
I forgot to add that my image has seaside (even though i don't use it). Perhaps I should step back and make certain I have the right starting image for playing around with these sockets. As I said in a prior email FTPClient appears to have a code error: It looks like the last line of FTPClient>>openPassiveDataConnection should be: self openDataSocket: remoteHostAddress asSocketAddress port: dataPort instead of (current code): self openDataSocket: remoteHostAddress port: dataPort By making this change, I can get down to Socket primitive errors with the FTP side of Monticello. I am not set up to contribute code, so, it would be nice if somebody else could check this out, and submit the fix. -cam
So is that in the exception block before you get the walkback on the socket allocation failure? On 30-Apr-09, at 8:45 AM, Cameron Sanders wrote:
Well, "Socket allInstances size inspect" is giving me numbers like 8, 6, or 2 from the "ScriptLoader loadOBAlpha" do-it. When I look at the process on the Mac (with the activity monitor), it says I have "Ports: 91". A look at "open files and ports" shows a lengthy list of filenames/devices that are open, but only about 35 show up. There are a few surprises (to me) in the open files list:
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
Very strange... After a while on linux, I have an error in MCHttpRepository>>#allFileNames 'Could not resolve the server named: source.lukas-renggli.ch' while executing: instClass lukas install: 'OB-Regex'; the 6 opened fd turned into many ... all pointing to the change file Pharo0.1Core-10281cl.changes ls -l /proc/7932/fd | wc -l 577 ls -l /proc/7932/fd | sort -n -k 8 | head -20 | grep -v '^total' lrwx------ 1 nicolas parents 64 2009-04-30 23:03 0 -> /dev/pts/3 lrwx------ 1 nicolas parents 64 2009-04-30 23:03 1 -> /dev/pts/3 lrwx------ 1 nicolas parents 64 2009-04-30 23:03 2 -> /dev/pts/3 lrwx------ 1 nicolas parents 64 2009-04-30 23:03 3 -> socket:[19987] lr-x------ 1 nicolas parents 64 2009-04-30 23:03 4 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/package-cache/ lr-x------ 1 nicolas parents 64 2009-04-30 23:03 5 -> /windata/Smalltalk/Squeak/SqueakV39.sources* lrwx------ 1 nicolas parents 64 2009-04-30 23:03 6 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 7 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 8 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 9 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 10 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 11 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 12 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 13 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 14 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 15 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 16 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 17 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 18 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* etc... Trying to restart, i have serverAdress 84.75.162.243(84-75-162-243.dclient.hispeed.ch),0(0) which I cannot ping outside squeak... So maybe squeak has correct diagnostic, but why all these opened change logs ? Nicolas 2009/4/30 John M McIntosh <johnmci@smalltalkconsulting.com>:
So is that in the exception block before you get the walkback on the socket allocation failure?
On 30-Apr-09, at 8:45 AM, Cameron Sanders wrote:
Well, "Socket allInstances size inspect" is giving me numbers like 8, 6, or 2 from the "ScriptLoader loadOBAlpha" do-it. When I look at the process on the Mac (with the activity monitor), it says I have "Ports: 91". A look at "open files and ports" shows a lengthy list of filenames/devices that are open, but only about 35 show up. There are a few surprises (to me) in the open files list:
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
With a simpler command, I reproduced the MC failure, but not the bunch of opened change log: 1) ScriptLoader new installingInstaller 2) Installer lukas install: 'OB-Regex'. I get this interesting message on the XTerm console: getaddrinfo: Name or service not known 2009/4/30 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
Very strange... After a while on linux, I have an error in MCHttpRepository>>#allFileNames
'Could not resolve the server named: source.lukas-renggli.ch'
while executing:
instClass lukas install: 'OB-Regex';
the 6 opened fd turned into many ... all pointing to the change file Pharo0.1Core-10281cl.changes
ls -l /proc/7932/fd | wc -l 577
ls -l /proc/7932/fd | sort -n -k 8 | head -20 | grep -v '^total' lrwx------ 1 nicolas parents 64 2009-04-30 23:03 0 -> /dev/pts/3 lrwx------ 1 nicolas parents 64 2009-04-30 23:03 1 -> /dev/pts/3 lrwx------ 1 nicolas parents 64 2009-04-30 23:03 2 -> /dev/pts/3 lrwx------ 1 nicolas parents 64 2009-04-30 23:03 3 -> socket:[19987] lr-x------ 1 nicolas parents 64 2009-04-30 23:03 4 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/package-cache/ lr-x------ 1 nicolas parents 64 2009-04-30 23:03 5 -> /windata/Smalltalk/Squeak/SqueakV39.sources* lrwx------ 1 nicolas parents 64 2009-04-30 23:03 6 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 7 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 8 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 9 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 10 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 11 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 12 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 13 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 14 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 15 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 16 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 17 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 18 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/Pharo0.1Core-10281cl.changes* etc...
Trying to restart, i have serverAdress 84.75.162.243(84-75-162-243.dclient.hispeed.ch),0(0) which I cannot ping outside squeak... So maybe squeak has correct diagnostic, but why all these opened change logs ?
Nicolas
2009/4/30 John M McIntosh <johnmci@smalltalkconsulting.com>:
So is that in the exception block before you get the walkback on the socket allocation failure?
On 30-Apr-09, at 8:45 AM, Cameron Sanders wrote:
Well, "Socket allInstances size inspect" is giving me numbers like 8, 6, or 2 from the "ScriptLoader loadOBAlpha" do-it. When I look at the process on the Mac (with the activity monitor), it says I have "Ports: 91". A look at "open files and ports" shows a lengthy list of filenames/devices that are open, but only about 35 show up. There are a few surprises (to me) in the open files list:
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On a 293/OSX, I get a primitive failed. When (HTTPSocket>>httpGetDocument: url args: args accept: mimeType request: requestString) calls (NetNameResolver addressForName: connectToHost timeout: 20.) connectToHost = '', which makes the primitive fail. Alexandre On 1 May 2009, at 00:11, Nicolas Cellier wrote:
With a simpler command, I reproduced the MC failure, but not the bunch of opened change log:
1) ScriptLoader new installingInstaller 2) Installer lukas install: 'OB-Regex'.
I get this interesting message on the XTerm console:
getaddrinfo: Name or service not known
2009/4/30 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
Very strange... After a while on linux, I have an error in MCHttpRepository>>#allFileNames
'Could not resolve the server named: source.lukas-renggli.ch'
while executing:
instClass lukas install: 'OB-Regex';
the 6 opened fd turned into many ... all pointing to the change file Pharo0.1Core-10281cl.changes
ls -l /proc/7932/fd | wc -l 577
ls -l /proc/7932/fd | sort -n -k 8 | head -20 | grep -v '^total' lrwx------ 1 nicolas parents 64 2009-04-30 23:03 0 -> /dev/pts/3 lrwx------ 1 nicolas parents 64 2009-04-30 23:03 1 -> /dev/pts/3 lrwx------ 1 nicolas parents 64 2009-04-30 23:03 2 -> /dev/pts/3 lrwx------ 1 nicolas parents 64 2009-04-30 23:03 3 -> socket:[19987] lr-x------ 1 nicolas parents 64 2009-04-30 23:03 4 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/package-cache/ lr-x------ 1 nicolas parents 64 2009-04-30 23:03 5 -> /windata/Smalltalk/Squeak/SqueakV39.sources* lrwx------ 1 nicolas parents 64 2009-04-30 23:03 6 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/ Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 7 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/ Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 8 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/ Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 9 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/ Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 10 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/ Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 11 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/ Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 12 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/ Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 13 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/ Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 14 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/ Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 15 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/ Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 16 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/ Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 17 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/ Pharo0.1Core-10281cl.changes* lr-x------ 1 nicolas parents 64 2009-04-30 23:03 18 -> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/ Pharo0.1Core-10281cl.changes* etc...
Trying to restart, i have serverAdress 84.75.162.243(84-75-162-243.dclient.hispeed.ch),0(0) which I cannot ping outside squeak... So maybe squeak has correct diagnostic, but why all these opened change logs ?
Nicolas
2009/4/30 John M McIntosh <johnmci@smalltalkconsulting.com>:
So is that in the exception block before you get the walkback on the socket allocation failure?
On 30-Apr-09, at 8:45 AM, Cameron Sanders wrote:
Well, "Socket allInstances size inspect" is giving me numbers like 8, 6, or 2 from the "ScriptLoader loadOBAlpha" do-it. When I look at the process on the Mac (with the activity monitor), it says I have "Ports: 91". A look at "open files and ports" shows a lengthy list of filenames/devices that are open, but only about 35 show up. There are a few surprises (to me) in the open files list:
-- = = = = = = = ==================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = = = = = ====================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
The Unix ipv6 logic translates the lookup error number into a string and prints to the console. If the name is "" an empty string, then yes it's EAI_NONAME see man 3 gai_strerror GAI_STRERROR(3) BSD Library Functions Manual GAI_STRERROR(3) NAME gai_strerror -- get error message string from EAI_xxx error code SYNOPSIS #include <sys/types.h> #include <sys/socket.h> #include <netdb.h> const char * gai_strerror(int ecode); DESCRIPTION The gai_strerror() function returns an error message string corresponding to the error code returned by getaddrinfo(3) or getnameinfo(3). The following error codes and their meaning are defined in <netdb.h>: EAI_AGAIN temporary failure in name resolution EAI_BADFLAGS invalid value for ai_flags EAI_BADHINTS invalid value for hints EAI_FAIL non-recoverable failure in name resolution EAI_FAMILY ai_family not supported EAI_MEMORY memory allocation failure EAI_NONAME hostname or servname not provided, or not known EAI_PROTOCOL resolved protocol is unknown EAI_SERVICE servname not supported for ai_socktype EAI_SOCKTYPE ai_socktype not supported EAI_SYSTEM system error returned in errno On 30-Apr-09, at 10:27 PM, Alexandre Bergel wrote:
On a 293/OSX, I get a primitive failed. When (HTTPSocket>>httpGetDocument: url args: args accept: mimeType request: requestString) calls (NetNameResolver addressForName: connectToHost timeout: 20.)
connectToHost = '', which makes the primitive fail.
Alexandre
On 1 May 2009, at 00:11, Nicolas Cellier wrote:
With a simpler command, I reproduced the MC failure, but not the bunch of opened change log:
1) ScriptLoader new installingInstaller 2) Installer lukas install: 'OB-Regex'.
I get this interesting message on the XTerm console:
getaddrinfo: Name or service not known
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
On Thu, Apr 30, 2009 at 11:48:52PM +0200, Nicolas Cellier wrote:
Very strange... After a while on linux, I have an error in MCHttpRepository>>#allFileNames
'Could not resolve the server named: source.lukas-renggli.ch'
while executing:
instClass lukas install: 'OB-Regex';
the 6 opened fd turned into many ... all pointing to the change file Pharo0.1Core-10281cl.changes
Well that's a bug for sure. Somebody is opening new file streams on the changes file, probably by accident. And not closing the one they opened last time. The bug in changes file handling could easily appear to be a socket problem, because the per-process limit on open descriptors would be shared between files and sockets (and pipes and ...). So find out why the changes file is being accidentally reopened, and the "socket problem" will probably go away. Dave
Well yes, and the magic check would be FileStream allSubInstances size inspect same place as the socket. Nothing of course finalization is involved in getting rid of zombie file handles too. And Dave is right you should only have one file handle open (read/ write) for *.changes On 30-Apr-09, at 4:30 PM, David T. Lewis wrote:
Well that's a bug for sure. Somebody is opening new file streams on the changes file, probably by accident. And not closing the one they opened last time.
The bug in changes file handling could easily appear to be a socket problem, because the per-process limit on open descriptors would be shared between files and sockets (and pipes and ...). So find out why the changes file is being accidentally reopened, and the "socket problem" will probably go away.
Dave
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
Hmm... I suspect my linux /proc has been foolished for some reason and it was in fact some sockets... I tried again, during loading, the socket opened and close and were recognized as such in /proc, but after a certain point, listing /proc/$pid/fd was reporting change log open and close... though the loading did continue normally. I will try the whole procedure again, but all this is really slow (I had some other traffic going on my limited bandwith). Nicolas 2009/5/1 John M McIntosh <johnmci@smalltalkconsulting.com>:
Well yes, and the magic check would be
FileStream allSubInstances size inspect
same place as the socket.
Nothing of course finalization is involved in getting rid of zombie file handles too.
And Dave is right you should only have one file handle open (read/ write) for *.changes
On 30-Apr-09, at 4:30 PM, David T. Lewis wrote:
Well that's a bug for sure. Somebody is opening new file streams on the changes file, probably by accident. And not closing the one they opened last time.
The bug in changes file handling could easily appear to be a socket problem, because the per-process limit on open descriptors would be shared between files and sockets (and pipes and ...). So find out why the changes file is being accidentally reopened, and the "socket problem" will probably go away.
Dave
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Forget it. I was the only one foolished :) strace showed it was effectively an attempt to open more than 1018 change log... Then in absence of garbage collect every socket attempt just fails... (Too many open files) If we find the guilty change log opener, this will fix the issue at least on my linux box. Otherwise inserting a retryWithGC: here and there is a possible temporary workaround... But those files will have to be closed... 2009/5/1 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
Hmm... I suspect my linux /proc has been foolished for some reason and it was in fact some sockets... I tried again, during loading, the socket opened and close and were recognized as such in /proc, but after a certain point, listing /proc/$pid/fd was reporting change log open and close... though the loading did continue normally. I will try the whole procedure again, but all this is really slow (I had some other traffic going on my limited bandwith). Nicolas
2009/5/1 John M McIntosh <johnmci@smalltalkconsulting.com>:
Well yes, and the magic check would be
FileStream allSubInstances size inspect
same place as the socket.
Nothing of course finalization is involved in getting rid of zombie file handles too.
And Dave is right you should only have one file handle open (read/ write) for *.changes
On 30-Apr-09, at 4:30 PM, David T. Lewis wrote:
Well that's a bug for sure. Somebody is opening new file streams on the changes file, probably by accident. And not closing the one they opened last time.
The bug in changes file handling could easily appear to be a socket problem, because the per-process limit on open descriptors would be shared between files and sockets (and pipes and ...). So find out why the changes file is being accidentally reopened, and the "socket problem" will probably go away.
Dave
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I can repeat my problem on linux, don't know if at all the same as Max users. It happens while doing: Installer wiresong project: 'ob'; install: 'OB-Refactory'. Once the load is finished: FileStream allSubInstances size -> 454 ls -l /proc/9091/fd | grep changes | wc -l -> 570 A little mismatch here... Note that it reached 1018 during load, for a total of 1024 opened fd, the upper limit... ls -l /proc/9091/fd | grep -v total | wc -l -> 1024 I can remove in image file stream: Smalltalk collectGarbage. FileStream allSubInstances size -> 4 But the file descriptors are not closed: ls -l /proc/9091/fd | grep changes | wc -l -> 570 Argh! After a garbage collect, I can proceed loading: Installer lukas project: 'omnibrowser'; install: 'OB-Regex'; install: 'OB-Tools' But dragging these 570 opened change log is not very sane... Gonna inquire if I can install a strace on my box. Nicolas 2009/5/1 John M McIntosh <johnmci@smalltalkconsulting.com>:
Well yes, and the magic check would be
FileStream allSubInstances size inspect
same place as the socket.
Nothing of course finalization is involved in getting rid of zombie file handles too.
And Dave is right you should only have one file handle open (read/ write) for *.changes
On 30-Apr-09, at 4:30 PM, David T. Lewis wrote:
Well that's a bug for sure. Somebody is opening new file streams on the changes file, probably by accident. And not closing the one they opened last time.
The bug in changes file handling could easily appear to be a socket problem, because the per-process limit on open descriptors would be shared between files and sockets (and pipes and ...). So find out why the changes file is being accidentally reopened, and the "socket problem" will probably go away.
Dave
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Strange, I have figures different from Nicolas: -- before ScriptLoader loadOBAlpha -- Socket allInstances size 0 HTTPSocket allInstances size 0 FileStream allInstances size 0 -- after ScriptLoader loadOBAlpha, the debugger is still up -- Socket allInstances size 0 HTTPSocket allInstances size 2 FileStream allInstances size 0 Alexandre On 1 May 2009, at 04:04, John M McIntosh wrote:
Well yes, and the magic check would be
FileStream allSubInstances size inspect
same place as the socket.
Nothing of course finalization is involved in getting rid of zombie file handles too.
And Dave is right you should only have one file handle open (read/ write) for *.changes
On 30-Apr-09, at 4:30 PM, David T. Lewis wrote:
Well that's a bug for sure. Somebody is opening new file streams on the changes file, probably by accident. And not closing the one they opened last time.
The bug in changes file handling could easily appear to be a socket problem, because the per-process limit on open descriptors would be shared between files and sockets (and pipes and ...). So find out why the changes file is being accidentally reopened, and the "socket problem" will probably go away.
Dave
-- = = = = = ====================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
That would be
FileStream allSubInstances size inspect
not FileStream allInstances size On 2-May-09, at 12:13 AM, Alexandre Bergel wrote:
Strange, I have figures different from Nicolas:
-- before ScriptLoader loadOBAlpha -- Socket allInstances size 0 HTTPSocket allInstances size 0 FileStream allInstances size 0
-- after ScriptLoader loadOBAlpha, the debugger is still up -- Socket allInstances size 0 HTTPSocket allInstances size 2 FileStream allInstances size 0
Alexandre
On 1 May 2009, at 04:04, John M McIntosh wrote:
Well yes, and the magic check would be
FileStream allSubInstances size inspect
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
-- before ScriptLoader loadOBAlpha -- Socket allSubInstances size 0 HTTPSocket allSubInstances size 0 FileStream allSubInstances size 4 -- after ScriptLoader loadOBAlpha, the debugger is still up -- Socket allSubInstances size 2 HTTPSocket allSubInstances size 2 FileStream allSubInstances size 56 Alexandre On 2 May 2009, at 09:14, John M McIntosh wrote:
That would be
FileStream allSubInstances size inspect
not
FileStream allInstances size
On 2-May-09, at 12:13 AM, Alexandre Bergel wrote:
Strange, I have figures different from Nicolas:
-- before ScriptLoader loadOBAlpha -- Socket allInstances size 0 HTTPSocket allInstances size 0 FileStream allInstances size 0
-- after ScriptLoader loadOBAlpha, the debugger is still up -- Socket allInstances size 0 HTTPSocket allInstances size 2 FileStream allInstances size 0
Alexandre
On 1 May 2009, at 04:04, John M McIntosh wrote:
Well yes, and the magic check would be
FileStream allSubInstances size inspect
-- = = = = = ====================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Apparnetly after 10296 I can load moose without problem. So the fixes of nicolas closing remoteString solved the problem. Now this is only partially solved since I would really like to understand why it broke in the first place since we did not touch this code. Stef
Oh, remoteString!!! I LOVE IT :))) Stephane, remember this mail ? I didn't sent it to list. Sending now, just as a reminder. 9 December 2008 05:20 subject One big mess :) Here is an IRC log me chatting with Keith. I just hope that Pharo guys will address this issue somewhere in future. [03:36] <sig__> btw, i just found your #7239 [03:36] <sig__> i'm also took a look at this code time ago [03:36] <sig__> and i would recommend following: [03:37] <sig__> - completely remove using RemoteString from practice. [03:37] <sig__> - make sure that access to source streams is synchronized [03:37] <sig__> (no concurrency issues) [03:37] *** optikalmouse (n=user@bas1-toronto10-1279398477.dsl.bell.ca) joined [03:38] <keithy> its a big job I started looking at it last wek [03:38] <sig__> RemoteString is very , very , very brittle thing [03:38] <keithy> do add you comment [03:39] <sig__> i wouldn't pass anything except actual source code outside source handling/management code [03:39] <keithy> definitely [03:39] <keithy> hmm [03:39] *** wgsilkie (n=aidan@203.109.162.247) joined [03:39] <keithy> or a proxy? [03:39] <sig__> remote string is a proxy! [03:40] <keithy> so... "I am a method" could I have my source please [03:40] <sig__> but you can easily damage source files with it [03:40] <sig__> or make it read complete mess instead of code [03:42] <sig__> because , from what i have seen, it assumes that there is nobody else accessing the source stream ATM, except single instance of RemoteString [03:46] <sig__> as well, as i don't like when different code in different classes able to manipulate with the source streams directly [03:46] <keithy> its ludicrous [03:46] <sig__> by passing array with two elements around [03:49] <sig__> check the references to SourceFiles :) [03:50] <sig__> 55 references in my image! [03:51] <sig__> a single, big, open wide security HOLE! :) [03:52] <keithy> and lots of horrible code [03:52] <sig__> yeah [03:52] *** wgsilkie quit (Remote closed the connection) [03:53] <sig__> (SourceFiles at: 2) [03:53] <sig__> very illustrative bit of code :) [03:54] *** bmp (n=benjamin@207-237-69-172.c3-0.avec-ubr3.nyr-avec.ny.static.cable.rcn.com) joined [03:55] <sig__> things like that makes me smile, when Edgar says "my image smaller , and therefore more modular" [03:55] <sig__> for GOD SAKE!! [03:59] <keithy> hmm, if you gzip the image does it get more modular? [04:00] <sig__> it is clear, that source management subsystem deserves a separate, well defined protocol. Without any exposure where it reads/takes source from, or where storing to [04:03] <sig__> and i can't call it a bug, it doesn't fits into any imaginable bugs category, simply because its not a bug, but design flaw [04:04] <sig__> and i think it would require few weeks to make it fixed [04:04] <keithy> an implementation flaw, no design obvious [04:04] *** lamneth2 (n=IceChat7@bas1-longueuil15-1176159811.dsl.bell.ca) joined [04:05] <sig__> well, an implementation should always follow a design [04:05] <sig__> actually a bug, to my sense, is an implementation flaw [04:06] <sig__> when it doesn't follows design [04:06] <sig__> but design flaw is when everything works (no bugs), but it works in an awfull way :) 2009/5/2 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Apparnetly after 10296 I can load moose without problem. So the fixes of nicolas closing remoteString solved the problem. Now this is only partially solved since I would really like to understand why it broke in the first place since we did not touch this code.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On May 3, 2009, at 1:09 AM, Igor Stasenko wrote:
Oh, remoteString!!! I LOVE IT :)))
Stephane, remember this mail ?
no :) but I agree we will have to address that in the future. But this will be a bit more complex
I didn't sent it to list. Sending now, just as a reminder.
9 December 2008 05:20 subject One big mess :)
Here is an IRC log me chatting with Keith.
I just hope that Pharo guys will address this issue somewhere in future.
[03:36] <sig__> btw, i just found your #7239 [03:36] <sig__> i'm also took a look at this code time ago [03:36] <sig__> and i would recommend following: [03:37] <sig__> - completely remove using RemoteString from practice. [03:37] <sig__> - make sure that access to source streams is synchronized [03:37] <sig__> (no concurrency issues) [03:37] *** optikalmouse (n=user@bas1- toronto10-1279398477.dsl.bell.ca) joined [03:38] <keithy> its a big job I started looking at it last wek [03:38] <sig__> RemoteString is very , very , very brittle thing
yes a terrible one :)
[03:38] <keithy> do add you comment [03:39] <sig__> i wouldn't pass anything except actual source code outside source handling/management code [03:39] <keithy> definitely [03:39] <keithy> hmm [03:39] *** wgsilkie (n=aidan@203.109.162.247) joined [03:39] <keithy> or a proxy? [03:39] <sig__> remote string is a proxy! [03:40] <keithy> so... "I am a method" could I have my source please [03:40] <sig__> but you can easily damage source files with it [03:40] <sig__> or make it read complete mess instead of code [03:42] <sig__> because , from what i have seen, it assumes that there is nobody else accessing the source stream ATM, except single instance of RemoteString [03:46] <sig__> as well, as i don't like when different code in different classes able to manipulate with the source streams directly [03:46] <keithy> its ludicrous [03:46] <sig__> by passing array with two elements around [03:49] <sig__> check the references to SourceFiles :) [03:50] <sig__> 55 references in my image! [03:51] <sig__> a single, big, open wide security HOLE! :) [03:52] <keithy> and lots of horrible code [03:52] <sig__> yeah
I totally agree.
[03:52] *** wgsilkie quit (Remote closed the connection) [03:53] <sig__> (SourceFiles at: 2) [03:53] <sig__> very illustrative bit of code :) [03:54] *** bmp (n=benjamin@207-237-69-172.c3-0.avec-ubr3.nyr-avec.ny.static.cable.rcn.com ) joined [03:55] <sig__> things like that makes me smile, when Edgar says "my image smaller , and therefore more modular" [03:55] <sig__> for GOD SAKE!! [03:59] <keithy> hmm, if you gzip the image does it get more modular? [04:00] <sig__> it is clear, that source management subsystem deserves a separate, well defined protocol. Without any exposure where it reads/takes source from, or where storing to [04:03] <sig__> and i can't call it a bug, it doesn't fits into any imaginable bugs category, simply because its not a bug, but design flaw [04:04] <sig__> and i think it would require few weeks to make it fixed [04:04] <keithy> an implementation flaw, no design obvious [04:04] *** lamneth2 (n=IceChat7@bas1-longueuil15-1176159811.dsl.bell.ca ) joined [04:05] <sig__> well, an implementation should always follow a design [04:05] <sig__> actually a bug, to my sense, is an implementation flaw [04:06] <sig__> when it doesn't follows design [04:06] <sig__> but design flaw is when everything works (no bugs), but it works in an awfull way :)
2009/5/2 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Apparnetly after 10296 I can load moose without problem. So the fixes of nicolas closing remoteString solved the problem. Now this is only partially solved since I would really like to understand why it broke in the first place since we did not touch this code.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Thanks Johan for such a deep insight. You're probably very close to the truth. I modified the priority of the finalization process to 61. The socket problem just vanished. It is hard to see whether this is a hack or this process should be at a higher priority by design. I googled a bit about finalization and priority processes to see whether java people have a similar issue, but I haven't find something relevant yet. Cheers, Alexandre On 30 Apr 2009, at 05:40, John M McIntosh wrote:
Further to this I"m wondering if there is something else "clever" going on.
Should the finalization process run at priority 61? See WeakArray>>restartFinalizationProcess Perhaps someone can check that?
Let me ramble on...
In the past you had the event polling going on at prioirty 40 in the 'UI process' That would grind away...
You also had the 'event tickler' that ran every 500 ms at priority 60.
And there in the middle why the key player here, the 'WeakArray finalization process' at 50
In this problem area, if we consider the socket creation fails because the number of sockets allocated has reached the limit (aka unix limit) not seen in windows. then this is because either (a) we are actualy holding onto thousands of sockets on purpose? Or we have 1, and thousands of zombies that have been tenured to OldSpace but not yet GCed, and Unix is unhappy with us.
Now when the socket create fails that causes well another pointless attempt at creation (why?) but also a full GC. The full GC will of course signal to the 'WeakArray finalization process' for it to gently destroy sockets.
But let's consider what's NEW here is the 'input events fetching process' is now running at 2x the speed of the older UI process and consuming 10-30% of the cpu? I'm not sure why before it was acceptable to look every 1/50 second, but now it has to be every 1/100 of a second.
But it's interesting that it''s running at priority 60, which means it's sucking CPU away from the weak array finalization process.
Now as we know the weak array finalization process is rather cpu intensive, so I wonder if there is just enough CPU taken away from finalization process so that it can't do enough work before the retry for the socket allocation leaps in and fails for a final time?
Well of course I'm not sure why the finalization process wouldn't finalize all the zombie sockets in one go when the full gc completes, but that would require some more testing...
On 29-Apr-09, at 8:09 PM, John M McIntosh wrote:
Er maybe someone doing the testing can stick a Socket allInstances size inspect in at the pointer where the exception is signaled. I think it would be enlightening what the value is.
On 29-Apr-09, at 7:52 PM, Cameron Sanders wrote:
Socket status must Unconnected before opening a new connection
-- = = = = = = ===================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = = =====================================================================
-- = = = = = ====================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Alexandre Bergel wrote:
Thanks Johan for such a deep insight. You're probably very close to the truth. I modified the priority of the finalization process to 61. The socket problem just vanished.
Great news! And a big thanks to John for the in depth analysis! So, should we just change the priority by default? What could be possible side effects? Michael
I would like to know why does the system rely on finalisation to release socket Apparently david mentioned that this is the source of huge problems. So what would be the alternative? Stef On Apr 30, 2009, at 12:00 PM, Michael Rueger wrote:
Alexandre Bergel wrote:
Thanks Johan for such a deep insight. You're probably very close to the truth. I modified the priority of the finalization process to 61. The socket problem just vanished.
Great news!
And a big thanks to John for the in depth analysis!
So, should we just change the priority by default? What could be possible side effects?
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Well somewhere someone needs to close the socket before it is *forgotten* On 30-Apr-09, at 5:29 AM, Stéphane Ducasse wrote:
I would like to know why does the system rely on finalisation to release socket Apparently david mentioned that this is the source of huge problems. So what would be the alternative?
Stef
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
Yes but why don't we close them with an ensure or something like that. I mean is the logic of the connection making it that we cannot use ensure or this is just a legacy? On Apr 30, 2009, at 7:20 PM, John M McIntosh wrote:
Well somewhere someone needs to close the socket before it is *forgotten*
On 30-Apr-09, at 5:29 AM, Stéphane Ducasse wrote:
I would like to know why does the system rely on finalisation to release socket Apparently david mentioned that this is the source of huge problems. So what would be the alternative?
Stef
-- = = = = = ====================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Beware: there are two issues here, not one. (a) the faulty remoteString code is ill behaved. Fine that can be fixed or as Igor suggested refactored to oblivion. (b) The deeper issue is that we affected how finalization works so that this ill behavior now causes application failure. If in the past it worked, now it doesn't I don't see anyone really having a good answer other than perhaps my guess, and how do we get back to the point were ill behaviour by *my* code won't cause Socket Failures. No doubt people have ugly code that is *silently* busted like RemoteString, but they don't know it. And as you saw actually finding the culprit is difficult. Lastly some people DO use finalization to do resource cleanup on purpose, not as a safety fallback, so they will be impacted I think by the new Pharo behaviour. Wasn't finalization tagged as bloated and need fixing? Igor I'm sure suggested a few things before the flurry of code for optimizing semaphores and process switching? On 2-May-09, at 1:52 PM, Stéphane Ducasse wrote:
Yes but why don't we close them with an ensure or something like that. I mean is the logic of the connection making it that we cannot use ensure or this is just a legacy?
On Apr 30, 2009, at 7:20 PM, John M McIntosh wrote:
Well somewhere someone needs to close the socket before it is *forgotten*
On 30-Apr-09, at 5:29 AM, Stéphane Ducasse wrote:
I would like to know why does the system rely on finalisation to release socket Apparently david mentioned that this is the source of huge problems. So what would be the alternative?
Stef
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
2009/5/3 John M McIntosh <johnmci@smalltalkconsulting.com>:
Beware: there are two issues here, not one.
(a) the faulty remoteString code is ill behaved. Fine that can be fixed or as Igor suggested refactored to oblivion.
IMO this should be done sooner or later. Its a pain to see it. Oh well, too bad, this is not the only thing which requires attention :)
(b) The deeper issue is that we affected how finalization works so that this ill behavior now causes application failure. If in the past it worked, now it doesn't I don't see anyone really having a good answer other than perhaps my guess, and how do we get back to the point were ill behaviour by *my* code won't cause Socket Failures.
I used finalization in my code multiple times. It didn't caused many problems, if you know how to do it right (by taking an implementation into account).
No doubt people have ugly code that is *silently* busted like RemoteString, but they don't know it. And as you saw actually finding the culprit is difficult.
Lastly some people DO use finalization to do resource cleanup on purpose, not as a safety fallback, so they will be impacted I think by the new Pharo behaviour.
It looks like i missed this part. Where i can read details about what is altered in finalization, which could break things?
Wasn't finalization tagged as bloated and need fixing? Igor I'm sure suggested a few things before the flurry of code for optimizing semaphores and process switching?
Yes, i proposed a little change to VM (just a couple lines of code in single method + registering additional special object) which would allow us more direct finalization. It not makes weak refs to be a full pledged ephemerons, but much easier to adopt in VM. And besides you wont find any finalization code in squeak which relies on ephemeron's special behavior -- reference 'value' slot weakly, only when reference in 'key' slot is dies. http://www.nabble.com/An-idea-about-better-finalization-support-td23186805.h...
On 2-May-09, at 1:52 PM, Stéphane Ducasse wrote:
-- Best regards, Igor Stasenko AKA sig.
On May 3, 2009, at 2:37 AM, Igor Stasenko wrote:
2009/5/3 John M McIntosh <johnmci@smalltalkconsulting.com>:
Beware: there are two issues here, not one.
(a) the faulty remoteString code is ill behaved. Fine that can be fixed or as Igor suggested refactored to oblivion.
IMO this should be done sooner or later. Its a pain to see it. Oh well, too bad, this is not the only thing which requires attention :)
(b) The deeper issue is that we affected how finalization works so that this ill behavior now causes application failure. If in the past it worked, now it doesn't I don't see anyone really having a good answer other than perhaps my guess, and how do we get back to the point were ill behaviour by *my* code won't cause Socket Failures.
I used finalization in my code multiple times. It didn't caused many problems, if you know how to do it right (by taking an implementation into account).
No doubt people have ugly code that is *silently* busted like RemoteString, but they don't know it. And as you saw actually finding the culprit is difficult.
Lastly some people DO use finalization to do resource cleanup on purpose, not as a safety fallback, so they will be impacted I think by the new Pharo behaviour.
It looks like i missed this part. Where i can read details about what is altered in finalization, which could break things?
In this thread or the one related john mentioned it.
Wasn't finalization tagged as bloated and need fixing? Igor I'm sure suggested a few things before the flurry of code for optimizing semaphores and process switching?
Yes, i proposed a little change to VM (just a couple lines of code in single method + registering additional special object) which would allow us more direct finalization. It not makes weak refs to be a full pledged ephemerons, but much easier to adopt in VM. And besides you wont find any finalization code in squeak which relies on ephemeron's special behavior -- reference 'value' slot weakly, only when reference in 'key' slot is dies.
http://www.nabble.com/An-idea-about-better-finalization-support-td23186805.h...
On 2-May-09, at 1:52 PM, Stéphane Ducasse wrote:
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
igor do you have a pointer on ephemerons because I forgot the details and these details are important. stef
2009/5/3 Stéphane Ducasse <stephane.ducasse@inria.fr>:
igor
do you have a pointer on ephemerons because I forgot the details and these details are important.
Please read that nabble thread (http://www.nabble.com/An-idea-about-better-finalization-support-td23186805.h...) , there are multiple pointers to ephemerons, like http://map.squeak.org/package/fe2a35f5-3f97-431e-8596-58e810aa3c72 which briefly describes what makes ephemeron's essential comparing to regular weak references.
stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On May 3, 2009, at 1:46 AM, John M McIntosh wrote:
Beware: there are two issues here, not one.
(a) the faulty remoteString code is ill behaved. Fine that can be fixed or as Igor suggested refactored to oblivion.
(b) The deeper issue is that we affected how finalization works so that this ill behavior now causes application failure. If in the past it worked, now it doesn't I don't see anyone really having a good answer other than perhaps my guess, and how do we get back to the point were ill behaviour by *my* code won't cause Socket Failures.
Yes this was also implied in my remark.
No doubt people have ugly code that is *silently* busted like RemoteString, but they don't know it. And as you saw actually finding the culprit is difficult.
Lastly some people DO use finalization to do resource cleanup on purpose, not as a safety fallback, so they will be impacted I think by the new Pharo behaviour.
I agree!
Wasn't finalization tagged as bloated and need fixing? Igor I'm sure suggested a few things before the flurry of code for optimizing semaphores and process switching?
On 2-May-09, at 1:52 PM, Stéphane Ducasse wrote:
Yes but why don't we close them with an ensure or something like that. I mean is the logic of the connection making it that we cannot use ensure or this is just a legacy?
On Apr 30, 2009, at 7:20 PM, John M McIntosh wrote:
Well somewhere someone needs to close the socket before it is *forgotten*
On 30-Apr-09, at 5:29 AM, Stéphane Ducasse wrote:
I would like to know why does the system rely on finalisation to release socket Apparently david mentioned that this is the source of huge problems. So what would be the alternative?
Stef
-- = = = = = ====================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/5/3 John M McIntosh <johnmci@smalltalkconsulting.com>:
Beware: there are two issues here, not one.
(a) the faulty remoteString code is ill behaved. Fine that can be fixed or as Igor suggested refactored to oblivion.
(b) The deeper issue is that we affected how finalization works so that this ill behavior now causes application failure. If in the past it worked, now it doesn't I don't see anyone really having a good answer other than perhaps my guess, and how do we get back to the point were ill behaviour by *my* code won't cause Socket Failures.
No doubt people have ugly code that is *silently* busted like RemoteString, but they don't know it. And as you saw actually finding the culprit is difficult.
Lastly some people DO use finalization to do resource cleanup on purpose, not as a safety fallback, so they will be impacted I think by the new Pharo behaviour.
Wasn't finalization tagged as bloated and need fixing? Igor I'm sure suggested a few things before the flurry of code for optimizing semaphores and process switching?
Yes! RemoteString patch is what I would call "un pansement sur une jambe de bois" unless it has more of "un arbre qui cache la forêt".. We need to write a SUnit TestCase stressing the finalization mechanism and identify what's going on. Debugging such low level high priority multi-process may imply instrumenting the VM though... Nicolas
On 2-May-09, at 1:52 PM, Stéphane Ducasse wrote:
Yes but why don't we close them with an ensure or something like that. I mean is the logic of the connection making it that we cannot use ensure or this is just a legacy?
On Apr 30, 2009, at 7:20 PM, John M McIntosh wrote:
Well somewhere someone needs to close the socket before it is *forgotten*
On 30-Apr-09, at 5:29 AM, Stéphane Ducasse wrote:
I would like to know why does the system rely on finalisation to release socket Apparently david mentioned that this is the source of huge problems. So what would be the alternative?
Stef
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I checked again, and apparently setting the priority of the finalization process to 61 does _not_ solve the socket problem. Maybe I did a wrong manipulation previously. Grrr... Alexandre On 30 Apr 2009, at 05:40, John M McIntosh wrote:
Further to this I"m wondering if there is something else "clever" going on.
Should the finalization process run at priority 61? See WeakArray>>restartFinalizationProcess Perhaps someone can check that?
Let me ramble on...
In the past you had the event polling going on at prioirty 40 in the 'UI process' That would grind away...
You also had the 'event tickler' that ran every 500 ms at priority 60.
And there in the middle why the key player here, the 'WeakArray finalization process' at 50
In this problem area, if we consider the socket creation fails because the number of sockets allocated has reached the limit (aka unix limit) not seen in windows. then this is because either (a) we are actualy holding onto thousands of sockets on purpose? Or we have 1, and thousands of zombies that have been tenured to OldSpace but not yet GCed, and Unix is unhappy with us.
Now when the socket create fails that causes well another pointless attempt at creation (why?) but also a full GC. The full GC will of course signal to the 'WeakArray finalization process' for it to gently destroy sockets.
But let's consider what's NEW here is the 'input events fetching process' is now running at 2x the speed of the older UI process and consuming 10-30% of the cpu? I'm not sure why before it was acceptable to look every 1/50 second, but now it has to be every 1/100 of a second.
But it's interesting that it''s running at priority 60, which means it's sucking CPU away from the weak array finalization process.
Now as we know the weak array finalization process is rather cpu intensive, so I wonder if there is just enough CPU taken away from finalization process so that it can't do enough work before the retry for the socket allocation leaps in and fails for a final time?
Well of course I'm not sure why the finalization process wouldn't finalize all the zombie sockets in one go when the full gc completes, but that would require some more testing...
On 29-Apr-09, at 8:09 PM, John M McIntosh wrote:
Er maybe someone doing the testing can stick a Socket allInstances size inspect in at the pointer where the exception is signaled. I think it would be enlightening what the value is.
On 29-Apr-09, at 7:52 PM, Cameron Sanders wrote:
Socket status must Unconnected before opening a new connection
-- = = = = = = ===================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = = =====================================================================
-- = = = = = ====================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Alexandre, you did mention having #port: sent to a ByteArray. It looks like the last line of FTPClient>>openPassiveDataConnection should be: self openDataSocket: remoteHostAddress asSocketAddress port: dataPort instead of (current code): self openDataSocket: remoteHostAddress port: dataPort With that change, the system drills on down and has a primitive failure in #port (on a Mac). I will add "Socket allInstances size inspect" just above the #port: method in Socket>>connectTo:port:. ... and the answer is SmallInteger: 7. Anything else I should inspect in here? -Cam PS: I am coming at this from the Monticello/FTP side, because my code is on an ftp server. On Apr 29, 2009, at 5:00 PM, Alexandre Bergel wrote:
Does not work for me. The problem is probably different. I still get a 'Socket status must Unconnected before opening a new connection'
Alexandre
On 29 Apr 2009, at 21:39, Nicolas Cellier wrote:
Could you test if this fix works:
PharoInbox/SLICE-M7343-Socket-Rollover-bug-nice.2
2009/4/29 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
OK guys, I think you loaded my rollover stuff... Mea maxima culpa:
#waitForDataUntil: and #waitForDataFor: DID NOT DO THE SAME THING!
the former signals ConnectionClosed, while the later silently answer false...
The reason it works on windws is probably I did not load my change (I used a different image...).
Strangely, I used Monticello on squeaksource without encountering this bug...
Nicolas
2009/4/29 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
Also note that it fails at the end of the progress bar. And inspecting response tempVar in HTTPSocket>>getRestOfBuffer: leads to:
collection copyFrom: readLimit-100 to: readLimit -> 'Standard.39-cwp.1.mcz</a> 18-Aug-2006 19:38 50K <hr></pre> </body></html> '
I don't want to learn anything about http protocol, but it sounds like the whole stream was correctly retrieved. That means something has changed in the order things are processed. We should test if it is a matter of VM or in image change.
Nicolas
2009/4/29 Michael Rueger <m.rueger@acm.org>:
Nicolas Cellier wrote:
I confirm it works on windows and fails on linux (exupery VM)
as it also fails on Mac it seems it could be the Unix socket code?
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
The Socket allInstances size inspect should go in the exception handler block before it throws the execption you don't want to see. On 29-Apr-09, at 8:58 PM, Cameron Sanders wrote:
Alexandre, you did mention having #port: sent to a ByteArray. It looks like the last line of FTPClient>>openPassiveDataConnection should be: self openDataSocket: remoteHostAddress asSocketAddress port: dataPort
instead of (current code): self openDataSocket: remoteHostAddress port: dataPort
With that change, the system drills on down and has a primitive failure in #port (on a Mac).
I will add "Socket allInstances size inspect" just above the #port: method in Socket>>connectTo:port:.
... and the answer is SmallInteger: 7. Anything else I should inspect in here?
-Cam PS: I am coming at this from the Monticello/FTP side, because my code is on an ftp server.
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
Hi Cam, The problem is likely to be the one pointed out by John Alexandre On 30 Apr 2009, at 05:58, Cameron Sanders wrote:
Alexandre, you did mention having #port: sent to a ByteArray. It looks like the last line of FTPClient>>openPassiveDataConnection should be: self openDataSocket: remoteHostAddress asSocketAddress port: dataPort
instead of (current code): self openDataSocket: remoteHostAddress port: dataPort
With that change, the system drills on down and has a primitive failure in #port (on a Mac).
I will add "Socket allInstances size inspect" just above the #port: method in Socket>>connectTo:port:.
... and the answer is SmallInteger: 7. Anything else I should inspect in here?
-Cam PS: I am coming at this from the Monticello/FTP side, because my code is on an ftp server.
On Apr 29, 2009, at 5:00 PM, Alexandre Bergel wrote:
Does not work for me. The problem is probably different. I still get a 'Socket status must Unconnected before opening a new connection'
Alexandre
On 29 Apr 2009, at 21:39, Nicolas Cellier wrote:
Could you test if this fix works:
PharoInbox/SLICE-M7343-Socket-Rollover-bug-nice.2
2009/4/29 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
OK guys, I think you loaded my rollover stuff... Mea maxima culpa:
#waitForDataUntil: and #waitForDataFor: DID NOT DO THE SAME THING!
the former signals ConnectionClosed, while the later silently answer false...
The reason it works on windws is probably I did not load my change (I used a different image...).
Strangely, I used Monticello on squeaksource without encountering this bug...
Nicolas
2009/4/29 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
Also note that it fails at the end of the progress bar. And inspecting response tempVar in HTTPSocket>>getRestOfBuffer: leads to:
collection copyFrom: readLimit-100 to: readLimit -> 'Standard.39-cwp.1.mcz</a> 18-Aug-2006 19:38 50K <hr></pre> </body></html> '
I don't want to learn anything about http protocol, but it sounds like the whole stream was correctly retrieved. That means something has changed in the order things are processed. We should test if it is a matter of VM or in image change.
Nicolas
2009/4/29 Michael Rueger <m.rueger@acm.org>:
Nicolas Cellier wrote:
I confirm it works on windows and fails on linux (exupery VM)
as it also fails on Mac it seems it could be the Unix socket code?
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
participants (9)
-
Alexandre Bergel -
Cameron Sanders -
David T. Lewis -
dmason＠mason-rose.ca -
Igor Stasenko -
John M McIntosh -
Michael Rueger -
Nicolas Cellier -
Stéphane Ducasse