I have updated the VMs, the issue should be resolved now. On Fri, Jul 16, 2021 at 12:10 PM Guillermo Polito <[email protected]> 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/bff77946691617acce104d8f38d60242fa1cc2bb > > Pablo is updating the stable VMs just in this moment. > > G > > > El 16 jul 2021, a las 12:07, Sven Van Caekenberghe <[email protected]> > escribió: > > > > Anyway, for now, I added guards: > > > > > https://github.com/svenvc/zinc/commit/cac2cb36410c24e9070f850b641e0cd02a05deb8 > > > https://github.com/svenvc/zodiac/commit/b12ba07f93ab73afad2523d75149c8b5440b2c64 > > > > but the core problem remains. > > > >> On 15 Jul 2021, at 21:35, Gabriel Cotelli <[email protected]> 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 <[email protected]> > wrote: > >> > >> > >>> On 15 Jul 2021, at 16:42, Gabriel Cotelli <[email protected]> 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 <[email protected]> > 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. [email protected]
