Thank you!

> On 16 Jul 2021, at 12:10, 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

Reply via email to