- Pharo-dev - lists.pharo.org

Re: [Zdc]SocketStream>>#openConnectionToHostNamed:port: no longer signals am exception on macOS

by tesonep＠gmail.com

Hi, with the new VM I could not reproduce it. I think it was related with the issue of the NetNameResolver. Which VM version are you using? Thanks On Sun, Jul 18, 2021 at 3:51 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > It seems that the following consistently crashes a recent/latest Pharo 9 > image/vm on macOS: > > (ZdcSocketStream openConnectionToHostNamed: 'localhost' port: 12335) > nextPut: 0; close. > > Command line, you can try it as follows: > > $ ./pharo Pharo.image eval "(ZdcSocketStream openConnectionToHostNamed: > 'localhost' port: 12335) nextPut: 0; close. #foo" > > You can replace ZdcSocketStream by SocketStream, same result. > > Before, trying to connect to a non-existing host:port resulted in a > ConnectionTimedOut: Cannot connect to 127.0.0.1:12335. > > Now, the code just returns and the bad stream is then used as if it is OK, > which results in a hard crash. > > Furthermore, there is no backtrace nor log. > > Sven > -- Pablo Tesone. tesonep(a)gmail.com

July 19, 2021

Progress Report -> Refactoring Project - ( July 12 - July 16)

by Evelyn Cusi Lopez

Hi everyone, Last week I did these tasks: - Improve parametrized tests. - Clean up previous tests of Refactoring1 and Refactoring2 classes. Check these changes in the: PR #9599 <https://github.com/pharo-project/pharo/pull/9599> - Update scope manager to integrate. Check changes here: Scope branch <https://github.com/pharo-project/pharo/compare/Pharo10...Lin777:ScopeManage…> - Split migration from tests to integrate into Pharo. Check changes here: Migration branch. <https://github.com/pharo-project/pharo/compare/Pharo10...Lin777:MigrateRefa…> It will integrate after parametrized tests. - Migrate new refactorings, these changes are in the previous branch Tasks for this week: <https://github.com/pharo-project/pharo/issues/9142> - Continue migrating refactorings. Some of them are: - RBExtractMethodRefactoring - RBFindAndReplaceRefactoring - RBExtractMethodAndOccurrences - RBExtractSetUpRefactoring - RBRenameMethodRefactoring - RBReplaceMethodRefactoring - RBInlineParameterRefactoring Best regards, Evelyn Cusi Lopez

July 19, 2021

[Zdc]SocketStream>>#openConnectionToHostNamed:port: no longer signals am exception on macOS

by Sven Van Caekenberghe

Hi, It seems that the following consistently crashes a recent/latest Pharo 9 image/vm on macOS: (ZdcSocketStream openConnectionToHostNamed: 'localhost' port: 12335) nextPut: 0; close. Command line, you can try it as follows: $ ./pharo Pharo.image eval "(ZdcSocketStream openConnectionToHostNamed: 'localhost' port: 12335) nextPut: 0; close. #foo" You can replace ZdcSocketStream by SocketStream, same result. Before, trying to connect to a non-existing host:port resulted in a ConnectionTimedOut: Cannot connect to 127.0.0.1:12335. Now, the code just returns and the bad stream is then used as if it is OK, which results in a hard crash. Furthermore, there is no backtrace nor log. Sven

July 18, 2021

Re: [ANN] Pharo 9 released!

by Esteban Maringolo

Thanks team. Impressive release. Keep up the good work! Esteban A. Maringolo On Thu, Jul 15, 2021 at 6:14 AM Esteban Lorenzano <estebanlm(a)netc.eu> wrote: > Dear World and dynamic language lovers: > > The time has come for Pharo 9 <https://pharo.org/> ! > > Pharo is a pure object-oriented programming language and a powerful > environment, focused on simplicity and immediate feedback. > > > Here are the key features of Pharo 9: > > > - Full redesign of the Spec UI framework (new logic, application, > style, GTK3 back-end) > - New tools: > - > - new playground, > - new object centric inspector, > - new object centric debugger. > - better and new Refactorings > - class comments are now written in Microdown format (Markdown > compatible) > - classes now can be defined using a "fluid" api (Preview) > - New completion framework that adapts better to edition contexts > and is customizable > - Fast universal non-blocking FFI which now uses libFFI as backend. > - Pharo now supports Windows, OSX, Linux (Ubuntu, Debian, Fedora, > openSUSE, Arch, Raspbian) and multiple architectures (Intel/ARM 32/64bits). > - Virtual Machine > - > - Idle VM > - Support for ARM 64bits > - Support for Apple M1 > - More than 3000 tests > - Built for Ubuntu 18.04, 19.04, 20.04, 21.04, 21.10; Debian 9, 10, > Testing; Fedora 32, 32, 34; openSUSE 15.1, 15.2, Tumbleweed; Manjaro; Arch > - Uses SDL 2.0 as back-end by default. It supports extended event > handling, including trackpad support. > - General speed up due to compiler optimisations and UI simplification. > - And many, many more tests. > > > These are just the more prominent highlights, but the details are just as > important. We have closed a massive amount of issues: around 1400 issues > and 2150 pull requests. > > A more extended changelog can be found at > https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo90Change… > . > > While the technical improvements are significant, still the most > impressive fact is that the new code that got in the main Pharo 9 image was > contributed by more than 90 people. > > Pharo is more than code. It is an exciting project involving a great > community. > > We thank all the contributors to this release: > > Aaron Bieber, Ackerley Tng, Alban Benmouffek, Ale Cossio, Alexandre > Bergel, Alistair Grant, Allex Oliveira, Angela Chia-Ling, Arturo Zambrano, > Asbathou Biyalou-Sama, Ben Coman, Benoit Verhaegue, Carlo Teixeira, Carlos > Lopez, Carolina Hernandez, Charles A. Monteiro, Christoph Thiede, > Christophe Demarey, Clotilde Toullec, Cyril Ferlicot, Damien Pollet, Daniel > Aparicio, David Bajger, David SÃ¡nchez i Gregori, Denis Kudriashov, Ellis > Harris, Eric Brandwein, Eric Gade, Erik Stel, ErikOnBike, Esteban > Lorenzano, Esteban Villalobos, Evelyn Cusi Lopez, Evelyn Cusi Lopez, Ewan > Dawson, Francis Pineda, Francis Pineda, Gabriel Omar Cotelli, Geraldine > Galindo, Giovanni Corriga, Guille Polito, Himanshu jld, Johan Brichau, > Jonathan van Alteren, Jordan Montt, Julien Delplanque, Kamil Kukura, Kasper > Ãsterbye, Kurt Kilpela, Laurine Dargaud, Marco Rimoldi, Marcus Denker, > Martin Dias, Martin McClure, Massimo Nocentini, Max Leske, Maximilian > Ignacio Willembrinck Santander, Milton Mamani Torres, Moussa Saker, > Myroslava Romaniuk, Nicolas Anquetil, Norbert Hartl, Nour Djihan, Oleksandr > Zaitsev, Pablo SÃ¡nchez RodrÃguez, Pablo Tesone, Pavel Krivanek, Philippe > Lesueur, Pierre Misse, Rakshit P., Rob Sayers, Roland Bernard, Ronie > Salgado, Sean DeNigris, Sebastian Jordan MontaÃ±o, Serge Stinckwich, Stephan > Eggermont, Steven Costiou, StÃ©phane Ducasse, Sven Van Caekenberghe, Thomas > Dupriez, ThÃ©o Lanord, ThÃ©o Rogliano, Todd Blanchard, Torsten Bergmann, > Vincent Blondeau, WÃ©slleymberg Lisboa. > > > (If you contributed with Pharo 9 development in any way and we missed your > name, please send us an email and we will add you). > > Enjoy! > > The Pharo Team > > Try Pharo: http://pharo.org/download <https://pharo.org/download> > > Learn Pharo: http://pharo.org/documentation > <https://pharo.org/documentation> >

July 16, 2021

Re: Serious NetNameResolver regression

by Sven Van Caekenberghe

thx. > On 16 Jul 2021, at 12:18, tesonep(a)gmail.com wrote: > > I have updated the VMs, the issue should be resolved now. > > On Fri, Jul 16, 2021 at 12:10 PM Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi all, > > it seems we need a new VM release. > The issue seems fixed since ~6 months ago > > https://github.com/pharo-project/opensmalltalk-vm/commit/bff77946691617acce… > > Pablo is updating the stable VMs just in this moment. > > G > > > El 16 jul 2021, a las 12:07, Sven Van Caekenberghe <sven(a)stfx.eu> escribiÃ³: > > > > Anyway, for now, I added guards: > > > > https://github.com/svenvc/zinc/commit/cac2cb36410c24e9070f850b641e0cd02a05d… > > https://github.com/svenvc/zodiac/commit/b12ba07f93ab73afad2523d75149c8b5440… > > > > but the core problem remains. > > > >> On 15 Jul 2021, at 21:35, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > >> > >> You're right Sven. The code in the image looks exactly the same betwen Pharo 8 and 9 but the behavior is different. > >> > >> On Thu, Jul 15, 2021 at 3:40 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >> > >>> On 15 Jul 2021, at 16:42, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > >>> > >>> Just doing > >>> NetNameResolver primStartLookupOfName:'unknown-stfx.eu';primNameLookupResult > >>> produces the bogus result. And both methods only call primitives in the SocketPlugin. So I think that no image code is responsible for the behavior change. > >> > >> I don't know, but your example is not good. You have to wait else the result is always 0.0.0.0 > >> > >> Pharo 7 > >> > >> NetNameResolver primStartLookupOfName:'unknown-stfx.eu'; waitForCompletionUntil: 5 > >> > >> false (signal exception) > >> > >> Pharo 9 > >> > >> NetNameResolver primStartLookupOfName:'unknown-stfx.eu'; waitForCompletionUntil: 5 > >> > >> true (bogus 0.0.0.0 result) > >> > >>> On Thu, Jul 15, 2021 at 11:36 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >>> Hi, > >>> > >>> It seems that we have a serious NetNameResolver regression: instead of signalling an exception, a bogus value is returned. > >>> > >>> Pharo 7: > >>> > >>> [ NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10 ] on: NameLookupFailure do: [ :exception | exception ]. > >>> > >>> "NameLookupFailure: cannot resolve 'unknown-stfx.eu'" > >>> > >>> Pharo 9: > >>> > >>> [ NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10 ] on: NameLookupFailure do: [ :exception | exception ]. > >>> > >>> "0.0.0.0" > >>> > >>> This is bad. What is even worse is that the following kills your image without leaving any trace (on macOS): > >>> > >>> ZnClient new get: 'http://unknown-stfx.eu'. > >>> > >>> Because it tries to connect to 0.0.0.0 > >>> > >>> On linux, at least there is a backtrace: > >>> > >>> sven@stfx-1:~/pharo$ rlwrap ./pharo reddit.image NeoConsole repl > >>> NeoConsole Pharo-9.0.0+build.1528.sha.29269ecfac2cbf6a56dfee232b7d3355e5cb77bd (64 Bit) > >>> pharo> NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10. > >>> > >>> 0.0.0.0 > >>> pharo> ZnClient new get: 'http://unknown-stfx.eu'. > >>> > >>> ConnectionTimedOut: Cannot connect to 0.0.0.0:80 > >>> [ConnectionTimedOut signal: 'Cannot connect to ' > >>> , (NetNameResolver stringFromAddress: hostAddress) , ':' , port asString] in Socket>>connectTo:port:waitForConnectionFor: > >>> Receiver: a Socket[unconnected] > >>> Arguments and temporary variables: > >>> hostAddress: 0.0.0.0 > >>> port: 80 > >>> timeout: 30 > >>> Receiver's instance variables: > >>> semaphore: a Semaphore() > >>> socketHandle: #[198 113 243 96 0 0 0 0 240 65 61 2 0 0 0 0] > >>> readSemaphore: a Semaphore() > >>> writeSemaphore: a Semaphore() > >>> > >>> Socket>>waitForConnectionFor:ifTimedOut: > >>> Socket>>connectTo:port:waitForConnectionFor: > >>> ZdcSocketStream(ZdcAbstractSocketStream)>>socketConnectTo:port: > >>> ZdcSocketStream(ZdcSimpleSocketStream)>>connectTo:port: > >>> ZdcSocketStream class(ZdcSimpleSocketStream class)>>openConnectionToHost:port:timeout: > >>> ZnNetworkingUtils>>socketStreamToUrlDirectly: > >>> ZnNetworkingUtils>>socketStreamToUrl: > >>> ZnNetworkingUtils class>>socketStreamToUrl: > >>> > >>> I had a quick look at changes to Network-Kernel but had no luck yet. > >>> > >>> Because of this running Zinc HTTP Components tests on macOS Pharo 9 also kills the image (ZnClientTest>>#testIfFailNonExistingHost). > >>> > >>> Of course, NetNameResolverTest does not do enough. > >>> > >>> Sven > > > -- > Pablo Tesone. > tesonep(a)gmail.com

July 16, 2021

Re: Serious NetNameResolver regression

by Sven Van Caekenberghe

Thank you! > On 16 Jul 2021, at 12:10, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi all, > > it seems we need a new VM release. > The issue seems fixed since ~6 months ago > > https://github.com/pharo-project/opensmalltalk-vm/commit/bff77946691617acce… > > Pablo is updating the stable VMs just in this moment. > > G > >> El 16 jul 2021, a las 12:07, Sven Van Caekenberghe <sven(a)stfx.eu> escribiÃ³: >> >> Anyway, for now, I added guards: >> >> https://github.com/svenvc/zinc/commit/cac2cb36410c24e9070f850b641e0cd02a05d… >> https://github.com/svenvc/zodiac/commit/b12ba07f93ab73afad2523d75149c8b5440… >> >> but the core problem remains. >> >>> On 15 Jul 2021, at 21:35, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: >>> >>> You're right Sven. The code in the image looks exactly the same betwen Pharo 8 and 9 but the behavior is different. >>> >>> On Thu, Jul 15, 2021 at 3:40 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> >>>> On 15 Jul 2021, at 16:42, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: >>>> >>>> Just doing >>>> NetNameResolver primStartLookupOfName:'unknown-stfx.eu';primNameLookupResult >>>> produces the bogus result. And both methods only call primitives in the SocketPlugin. So I think that no image code is responsible for the behavior change. >>> >>> I don't know, but your example is not good. You have to wait else the result is always 0.0.0.0 >>> >>> Pharo 7 >>> >>> NetNameResolver primStartLookupOfName:'unknown-stfx.eu'; waitForCompletionUntil: 5 >>> >>> false (signal exception) >>> >>> Pharo 9 >>> >>> NetNameResolver primStartLookupOfName:'unknown-stfx.eu'; waitForCompletionUntil: 5 >>> >>> true (bogus 0.0.0.0 result) >>> >>>> On Thu, Jul 15, 2021 at 11:36 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> Hi, >>>> >>>> It seems that we have a serious NetNameResolver regression: instead of signalling an exception, a bogus value is returned. >>>> >>>> Pharo 7: >>>> >>>> [ NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10 ] on: NameLookupFailure do: [ :exception | exception ]. >>>> >>>> "NameLookupFailure: cannot resolve 'unknown-stfx.eu'" >>>> >>>> Pharo 9: >>>> >>>> [ NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10 ] on: NameLookupFailure do: [ :exception | exception ]. >>>> >>>> "0.0.0.0" >>>> >>>> This is bad. What is even worse is that the following kills your image without leaving any trace (on macOS): >>>> >>>> ZnClient new get: 'http://unknown-stfx.eu'. >>>> >>>> Because it tries to connect to 0.0.0.0 >>>> >>>> On linux, at least there is a backtrace: >>>> >>>> sven@stfx-1:~/pharo$ rlwrap ./pharo reddit.image NeoConsole repl >>>> NeoConsole Pharo-9.0.0+build.1528.sha.29269ecfac2cbf6a56dfee232b7d3355e5cb77bd (64 Bit) >>>> pharo> NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10. >>>> >>>> 0.0.0.0 >>>> pharo> ZnClient new get: 'http://unknown-stfx.eu'. >>>> >>>> ConnectionTimedOut: Cannot connect to 0.0.0.0:80 >>>> [ConnectionTimedOut signal: 'Cannot connect to ' >>>> , (NetNameResolver stringFromAddress: hostAddress) , ':' , port asString] in Socket>>connectTo:port:waitForConnectionFor: >>>> Receiver: a Socket[unconnected] >>>> Arguments and temporary variables: >>>> hostAddress: 0.0.0.0 >>>> port: 80 >>>> timeout: 30 >>>> Receiver's instance variables: >>>> semaphore: a Semaphore() >>>> socketHandle: #[198 113 243 96 0 0 0 0 240 65 61 2 0 0 0 0] >>>> readSemaphore: a Semaphore() >>>> writeSemaphore: a Semaphore() >>>> >>>> Socket>>waitForConnectionFor:ifTimedOut: >>>> Socket>>connectTo:port:waitForConnectionFor: >>>> ZdcSocketStream(ZdcAbstractSocketStream)>>socketConnectTo:port: >>>> ZdcSocketStream(ZdcSimpleSocketStream)>>connectTo:port: >>>> ZdcSocketStream class(ZdcSimpleSocketStream class)>>openConnectionToHost:port:timeout: >>>> ZnNetworkingUtils>>socketStreamToUrlDirectly: >>>> ZnNetworkingUtils>>socketStreamToUrl: >>>> ZnNetworkingUtils class>>socketStreamToUrl: >>>> >>>> I had a quick look at changes to Network-Kernel but had no luck yet. >>>> >>>> Because of this running Zinc HTTP Components tests on macOS Pharo 9 also kills the image (ZnClientTest>>#testIfFailNonExistingHost). >>>> >>>> Of course, NetNameResolverTest does not do enough. >>>> >>>> Sven

July 16, 2021

Re: Serious NetNameResolver regression

by Tim Mackinnon

You guys are awesome - such a great community. > On 16 Jul 2021, at 12:18, tesonep(a)gmail.com wrote: > > I have updated the VMs, the issue should be resolved now. > > On Fri, Jul 16, 2021 at 12:10 PM Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: > Hi all, > > it seems we need a new VM release. > The issue seems fixed since ~6 months ago > > https://github.com/pharo-project/opensmalltalk-vm/commit/bff77946691617acce… <https://github.com/pharo-project/opensmalltalk-vm/commit/bff77946691617acce…> > > Pablo is updating the stable VMs just in this moment. > > G > > > El 16 jul 2021, a las 12:07, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> escribiÃ³: > > > > Anyway, for now, I added guards: > > > > https://github.com/svenvc/zinc/commit/cac2cb36410c24e9070f850b641e0cd02a05d… <https://github.com/svenvc/zinc/commit/cac2cb36410c24e9070f850b641e0cd02a05d…> > > https://github.com/svenvc/zodiac/commit/b12ba07f93ab73afad2523d75149c8b5440… <https://github.com/svenvc/zodiac/commit/b12ba07f93ab73afad2523d75149c8b5440…> > > > > but the core problem remains. > > > >> On 15 Jul 2021, at 21:35, Gabriel Cotelli <g.cotelli(a)gmail.com <mailto:g.cotelli@gmail.com>> wrote: > >> > >> You're right Sven. The code in the image looks exactly the same betwen Pharo 8 and 9 but the behavior is different. > >> > >> On Thu, Jul 15, 2021 at 3:40 PM Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: > >> > >> > >>> On 15 Jul 2021, at 16:42, Gabriel Cotelli <g.cotelli(a)gmail.com <mailto:g.cotelli@gmail.com>> wrote: > >>> > >>> Just doing > >>> NetNameResolver primStartLookupOfName:'unknown-stfx.eu <http://unknown-stfx.eu/>';primNameLookupResult > >>> produces the bogus result. And both methods only call primitives in the SocketPlugin. So I think that no image code is responsible for the behavior change. > >> > >> I don't know, but your example is not good. You have to wait else the result is always 0.0.0.0 > >> > >> Pharo 7 > >> > >> NetNameResolver primStartLookupOfName:'unknown-stfx.eu <http://unknown-stfx.eu/>'; waitForCompletionUntil: 5 > >> > >> false (signal exception) > >> > >> Pharo 9 > >> > >> NetNameResolver primStartLookupOfName:'unknown-stfx.eu <http://unknown-stfx.eu/>'; waitForCompletionUntil: 5 > >> > >> true (bogus 0.0.0.0 result) > >> > >>> On Thu, Jul 15, 2021 at 11:36 AM Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: > >>> Hi, > >>> > >>> It seems that we have a serious NetNameResolver regression: instead of signalling an exception, a bogus value is returned. > >>> > >>> Pharo 7: > >>> > >>> [ NetNameResolver addressForName: 'unknown-stfx.eu <http://unknown-stfx.eu/>' timeout: 10 ] on: NameLookupFailure do: [ :exception | exception ]. > >>> > >>> "NameLookupFailure: cannot resolve 'unknown-stfx.eu <http://unknown-stfx.eu/>'" > >>> > >>> Pharo 9: > >>> > >>> [ NetNameResolver addressForName: 'unknown-stfx.eu <http://unknown-stfx.eu/>' timeout: 10 ] on: NameLookupFailure do: [ :exception | exception ]. > >>> > >>> "0.0.0.0" > >>> > >>> This is bad. What is even worse is that the following kills your image without leaving any trace (on macOS): > >>> > >>> ZnClient new get: 'http://unknown-stfx.eu <http://unknown-stfx.eu/>'. > >>> > >>> Because it tries to connect to 0.0.0.0 > >>> > >>> On linux, at least there is a backtrace: > >>> > >>> sven@stfx-1:~/pharo$ rlwrap ./pharo reddit.image NeoConsole repl > >>> NeoConsole Pharo-9.0.0+build.1528.sha.29269ecfac2cbf6a56dfee232b7d3355e5cb77bd (64 Bit) > >>> pharo> NetNameResolver addressForName: 'unknown-stfx.eu <http://unknown-stfx.eu/>' timeout: 10. > >>> > >>> 0.0.0.0 > >>> pharo> ZnClient new get: 'http://unknown-stfx.eu <http://unknown-stfx.eu/>'. > >>> > >>> ConnectionTimedOut: Cannot connect to 0.0.0.0:80 <http://0.0.0.0/> > >>> [ConnectionTimedOut signal: 'Cannot connect to ' > >>> , (NetNameResolver stringFromAddress: hostAddress) , ':' , port asString] in Socket>>connectTo:port:waitForConnectionFor: > >>> Receiver: a Socket[unconnected] > >>> Arguments and temporary variables: > >>> hostAddress: 0.0.0.0 > >>> port: 80 > >>> timeout: 30 > >>> Receiver's instance variables: > >>> semaphore: a Semaphore() > >>> socketHandle: #[198 113 243 96 0 0 0 0 240 65 61 2 0 0 0 0] > >>> readSemaphore: a Semaphore() > >>> writeSemaphore: a Semaphore() > >>> > >>> Socket>>waitForConnectionFor:ifTimedOut: > >>> Socket>>connectTo:port:waitForConnectionFor: > >>> ZdcSocketStream(ZdcAbstractSocketStream)>>socketConnectTo:port: > >>> ZdcSocketStream(ZdcSimpleSocketStream)>>connectTo:port: > >>> ZdcSocketStream class(ZdcSimpleSocketStream class)>>openConnectionToHost:port:timeout: > >>> ZnNetworkingUtils>>socketStreamToUrlDirectly: > >>> ZnNetworkingUtils>>socketStreamToUrl: > >>> ZnNetworkingUtils class>>socketStreamToUrl: > >>> > >>> I had a quick look at changes to Network-Kernel but had no luck yet. > >>> > >>> Because of this running Zinc HTTP Components tests on macOS Pharo 9 also kills the image (ZnClientTest>>#testIfFailNonExistingHost). > >>> > >>> Of course, NetNameResolverTest does not do enough. > >>> > >>> Sven > > > -- > Pablo Tesone. > tesonep(a)gmail.com <mailto:tesonep@gmail.com>

July 16, 2021

Re: Serious NetNameResolver regression

by tesonep＠gmail.com

I have updated the VMs, the issue should be resolved now. On Fri, Jul 16, 2021 at 12:10 PM Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi all, > > it seems we need a new VM release. > The issue seems fixed since ~6 months ago > > > https://github.com/pharo-project/opensmalltalk-vm/commit/bff77946691617acce… > > Pablo is updating the stable VMs just in this moment. > > G > > > El 16 jul 2021, a las 12:07, Sven Van Caekenberghe <sven(a)stfx.eu> > escribiÃ³: > > > > Anyway, for now, I added guards: > > > > > https://github.com/svenvc/zinc/commit/cac2cb36410c24e9070f850b641e0cd02a05d… > > > https://github.com/svenvc/zodiac/commit/b12ba07f93ab73afad2523d75149c8b5440… > > > > but the core problem remains. > > > >> On 15 Jul 2021, at 21:35, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > >> > >> You're right Sven. The code in the image looks exactly the same betwen > Pharo 8 and 9 but the behavior is different. > >> > >> On Thu, Jul 15, 2021 at 3:40 PM Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> > >> > >>> On 15 Jul 2021, at 16:42, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > >>> > >>> Just doing > >>> NetNameResolver primStartLookupOfName:'unknown-stfx.eu > ';primNameLookupResult > >>> produces the bogus result. And both methods only call primitives in > the SocketPlugin. So I think that no image code is responsible for the > behavior change. > >> > >> I don't know, but your example is not good. You have to wait else the > result is always 0.0.0.0 > >> > >> Pharo 7 > >> > >> NetNameResolver primStartLookupOfName:'unknown-stfx.eu'; > waitForCompletionUntil: 5 > >> > >> false (signal exception) > >> > >> Pharo 9 > >> > >> NetNameResolver primStartLookupOfName:'unknown-stfx.eu'; > waitForCompletionUntil: 5 > >> > >> true (bogus 0.0.0.0 result) > >> > >>> On Thu, Jul 15, 2021 at 11:36 AM Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >>> Hi, > >>> > >>> It seems that we have a serious NetNameResolver regression: instead of > signalling an exception, a bogus value is returned. > >>> > >>> Pharo 7: > >>> > >>> [ NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10 ] on: > NameLookupFailure do: [ :exception | exception ]. > >>> > >>> "NameLookupFailure: cannot resolve 'unknown-stfx.eu'" > >>> > >>> Pharo 9: > >>> > >>> [ NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10 ] on: > NameLookupFailure do: [ :exception | exception ]. > >>> > >>> "0.0.0.0" > >>> > >>> This is bad. What is even worse is that the following kills your image > without leaving any trace (on macOS): > >>> > >>> ZnClient new get: 'http://unknown-stfx.eu'. > >>> > >>> Because it tries to connect to 0.0.0.0 > >>> > >>> On linux, at least there is a backtrace: > >>> > >>> sven@stfx-1:~/pharo$ rlwrap ./pharo reddit.image NeoConsole repl > >>> NeoConsole > Pharo-9.0.0+build.1528.sha.29269ecfac2cbf6a56dfee232b7d3355e5cb77bd (64 Bit) > >>> pharo> NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10. > >>> > >>> 0.0.0.0 > >>> pharo> ZnClient new get: 'http://unknown-stfx.eu'. > >>> > >>> ConnectionTimedOut: Cannot connect to 0.0.0.0:80 > >>> [ConnectionTimedOut signal: 'Cannot connect to ' > >>> , (NetNameResolver > stringFromAddress: hostAddress) , ':' , port asString] in > Socket>>connectTo:port:waitForConnectionFor: > >>> Receiver: a Socket[unconnected] > >>> Arguments and temporary variables: > >>> hostAddress: 0.0.0.0 > >>> port: 80 > >>> timeout: 30 > >>> Receiver's instance variables: > >>> semaphore: a Semaphore() > >>> socketHandle: #[198 113 243 96 0 0 0 0 240 65 61 2 0 > 0 0 0] > >>> readSemaphore: a Semaphore() > >>> writeSemaphore: a Semaphore() > >>> > >>> Socket>>waitForConnectionFor:ifTimedOut: > >>> Socket>>connectTo:port:waitForConnectionFor: > >>> ZdcSocketStream(ZdcAbstractSocketStream)>>socketConnectTo:port: > >>> ZdcSocketStream(ZdcSimpleSocketStream)>>connectTo:port: > >>> ZdcSocketStream class(ZdcSimpleSocketStream > class)>>openConnectionToHost:port:timeout: > >>> ZnNetworkingUtils>>socketStreamToUrlDirectly: > >>> ZnNetworkingUtils>>socketStreamToUrl: > >>> ZnNetworkingUtils class>>socketStreamToUrl: > >>> > >>> I had a quick look at changes to Network-Kernel but had no luck yet. > >>> > >>> Because of this running Zinc HTTP Components tests on macOS Pharo 9 > also kills the image (ZnClientTest>>#testIfFailNonExistingHost). > >>> > >>> Of course, NetNameResolverTest does not do enough. > >>> > >>> Sven > -- Pablo Tesone. tesonep(a)gmail.com

July 16, 2021

Re: Serious NetNameResolver regression

by Guillermo Polito

Hi all, it seems we need a new VM release. The issue seems fixed since ~6 months ago https://github.com/pharo-project/opensmalltalk-vm/commit/bff77946691617acce… Pablo is updating the stable VMs just in this moment. G > El 16 jul 2021, a las 12:07, Sven Van Caekenberghe <sven(a)stfx.eu> escribiÃ³: > > Anyway, for now, I added guards: > > https://github.com/svenvc/zinc/commit/cac2cb36410c24e9070f850b641e0cd02a05d… > https://github.com/svenvc/zodiac/commit/b12ba07f93ab73afad2523d75149c8b5440… > > but the core problem remains. > >> On 15 Jul 2021, at 21:35, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: >> >> You're right Sven. The code in the image looks exactly the same betwen Pharo 8 and 9 but the behavior is different. >> >> On Thu, Jul 15, 2021 at 3:40 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >>> On 15 Jul 2021, at 16:42, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: >>> >>> Just doing >>> NetNameResolver primStartLookupOfName:'unknown-stfx.eu';primNameLookupResult >>> produces the bogus result. And both methods only call primitives in the SocketPlugin. So I think that no image code is responsible for the behavior change. >> >> I don't know, but your example is not good. You have to wait else the result is always 0.0.0.0 >> >> Pharo 7 >> >> NetNameResolver primStartLookupOfName:'unknown-stfx.eu'; waitForCompletionUntil: 5 >> >> false (signal exception) >> >> Pharo 9 >> >> NetNameResolver primStartLookupOfName:'unknown-stfx.eu'; waitForCompletionUntil: 5 >> >> true (bogus 0.0.0.0 result) >> >>> On Thu, Jul 15, 2021 at 11:36 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> Hi, >>> >>> It seems that we have a serious NetNameResolver regression: instead of signalling an exception, a bogus value is returned. >>> >>> Pharo 7: >>> >>> [ NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10 ] on: NameLookupFailure do: [ :exception | exception ]. >>> >>> "NameLookupFailure: cannot resolve 'unknown-stfx.eu'" >>> >>> Pharo 9: >>> >>> [ NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10 ] on: NameLookupFailure do: [ :exception | exception ]. >>> >>> "0.0.0.0" >>> >>> This is bad. What is even worse is that the following kills your image without leaving any trace (on macOS): >>> >>> ZnClient new get: 'http://unknown-stfx.eu'. >>> >>> Because it tries to connect to 0.0.0.0 >>> >>> On linux, at least there is a backtrace: >>> >>> sven@stfx-1:~/pharo$ rlwrap ./pharo reddit.image NeoConsole repl >>> NeoConsole Pharo-9.0.0+build.1528.sha.29269ecfac2cbf6a56dfee232b7d3355e5cb77bd (64 Bit) >>> pharo> NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10. >>> >>> 0.0.0.0 >>> pharo> ZnClient new get: 'http://unknown-stfx.eu'. >>> >>> ConnectionTimedOut: Cannot connect to 0.0.0.0:80 >>> [ConnectionTimedOut signal: 'Cannot connect to ' >>> , (NetNameResolver stringFromAddress: hostAddress) , ':' , port asString] in Socket>>connectTo:port:waitForConnectionFor: >>> Receiver: a Socket[unconnected] >>> Arguments and temporary variables: >>> hostAddress: 0.0.0.0 >>> port: 80 >>> timeout: 30 >>> Receiver's instance variables: >>> semaphore: a Semaphore() >>> socketHandle: #[198 113 243 96 0 0 0 0 240 65 61 2 0 0 0 0] >>> readSemaphore: a Semaphore() >>> writeSemaphore: a Semaphore() >>> >>> Socket>>waitForConnectionFor:ifTimedOut: >>> Socket>>connectTo:port:waitForConnectionFor: >>> ZdcSocketStream(ZdcAbstractSocketStream)>>socketConnectTo:port: >>> ZdcSocketStream(ZdcSimpleSocketStream)>>connectTo:port: >>> ZdcSocketStream class(ZdcSimpleSocketStream class)>>openConnectionToHost:port:timeout: >>> ZnNetworkingUtils>>socketStreamToUrlDirectly: >>> ZnNetworkingUtils>>socketStreamToUrl: >>> ZnNetworkingUtils class>>socketStreamToUrl: >>> >>> I had a quick look at changes to Network-Kernel but had no luck yet. >>> >>> Because of this running Zinc HTTP Components tests on macOS Pharo 9 also kills the image (ZnClientTest>>#testIfFailNonExistingHost). >>> >>> Of course, NetNameResolverTest does not do enough. >>> >>> Sven

July 16, 2021

Re: Serious NetNameResolver regression

by Sven Van Caekenberghe

Anyway, for now, I added guards: https://github.com/svenvc/zinc/commit/cac2cb36410c24e9070f850b641e0cd02a05d… https://github.com/svenvc/zodiac/commit/b12ba07f93ab73afad2523d75149c8b5440… but the core problem remains. > On 15 Jul 2021, at 21:35, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > You're right Sven. The code in the image looks exactly the same betwen Pharo 8 and 9 but the behavior is different. > > On Thu, Jul 15, 2021 at 3:40 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 15 Jul 2021, at 16:42, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > > > Just doing > > NetNameResolver primStartLookupOfName:'unknown-stfx.eu';primNameLookupResult > > produces the bogus result. And both methods only call primitives in the SocketPlugin. So I think that no image code is responsible for the behavior change. > > I don't know, but your example is not good. You have to wait else the result is always 0.0.0.0 > > Pharo 7 > > NetNameResolver primStartLookupOfName:'unknown-stfx.eu'; waitForCompletionUntil: 5 > > false (signal exception) > > Pharo 9 > > NetNameResolver primStartLookupOfName:'unknown-stfx.eu'; waitForCompletionUntil: 5 > > true (bogus 0.0.0.0 result) > > > On Thu, Jul 15, 2021 at 11:36 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > > > It seems that we have a serious NetNameResolver regression: instead of signalling an exception, a bogus value is returned. > > > > Pharo 7: > > > > [ NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10 ] on: NameLookupFailure do: [ :exception | exception ]. > > > > "NameLookupFailure: cannot resolve 'unknown-stfx.eu'" > > > > Pharo 9: > > > > [ NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10 ] on: NameLookupFailure do: [ :exception | exception ]. > > > > "0.0.0.0" > > > > This is bad. What is even worse is that the following kills your image without leaving any trace (on macOS): > > > > ZnClient new get: 'http://unknown-stfx.eu'. > > > > Because it tries to connect to 0.0.0.0 > > > > On linux, at least there is a backtrace: > > > > sven@stfx-1:~/pharo$ rlwrap ./pharo reddit.image NeoConsole repl > > NeoConsole Pharo-9.0.0+build.1528.sha.29269ecfac2cbf6a56dfee232b7d3355e5cb77bd (64 Bit) > > pharo> NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10. > > > > 0.0.0.0 > > pharo> ZnClient new get: 'http://unknown-stfx.eu'. > > > > ConnectionTimedOut: Cannot connect to 0.0.0.0:80 > > [ConnectionTimedOut signal: 'Cannot connect to ' > > , (NetNameResolver stringFromAddress: hostAddress) , ':' , port asString] in Socket>>connectTo:port:waitForConnectionFor: > > Receiver: a Socket[unconnected] > > Arguments and temporary variables: > > hostAddress: 0.0.0.0 > > port: 80 > > timeout: 30 > > Receiver's instance variables: > > semaphore: a Semaphore() > > socketHandle: #[198 113 243 96 0 0 0 0 240 65 61 2 0 0 0 0] > > readSemaphore: a Semaphore() > > writeSemaphore: a Semaphore() > > > > Socket>>waitForConnectionFor:ifTimedOut: > > Socket>>connectTo:port:waitForConnectionFor: > > ZdcSocketStream(ZdcAbstractSocketStream)>>socketConnectTo:port: > > ZdcSocketStream(ZdcSimpleSocketStream)>>connectTo:port: > > ZdcSocketStream class(ZdcSimpleSocketStream class)>>openConnectionToHost:port:timeout: > > ZnNetworkingUtils>>socketStreamToUrlDirectly: > > ZnNetworkingUtils>>socketStreamToUrl: > > ZnNetworkingUtils class>>socketStreamToUrl: > > > > I had a quick look at changes to Network-Kernel but had no luck yet. > > > > Because of this running Zinc HTTP Components tests on macOS Pharo 9 also kills the image (ZnClientTest>>#testIfFailNonExistingHost). > > > > Of course, NetNameResolverTest does not do enough. > > > > Sven

July 16, 2021