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
