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 >
