> On 15 Jul 2021, at 16:42, Gabriel Cotelli <g.cote...@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 <s...@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

Reply via email to