Serious NetNameResolver regression
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
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.
On Thu, Jul 15, 2021 at 11:36 AM Sven Van Caekenberghe sven@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
On 15 Jul 2021, at 16:42, Gabriel Cotelli g.cotelli@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 sven@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
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 sven@stfx.eu wrote:
On 15 Jul 2021, at 16:42, Gabriel Cotelli g.cotelli@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 sven@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
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 g.cotelli@gmail.com 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 sven@stfx.eu wrote:
On 15 Jul 2021, at 16:42, Gabriel Cotelli g.cotelli@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 sven@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
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 sven@stfx.eu 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 g.cotelli@gmail.com 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 sven@stfx.eu wrote:
On 15 Jul 2021, at 16:42, Gabriel Cotelli g.cotelli@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 sven@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
I have updated the VMs, the issue should be resolved now.
On Fri, Jul 16, 2021 at 12:10 PM Guillermo Polito guillermopolito@gmail.com
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 sven@stfx.eu
escribió:
Anyway, for now, I added guards:
but the core problem remains.
On 15 Jul 2021, at 21:35, Gabriel Cotelli g.cotelli@gmail.com 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 sven@stfx.eu
wrote:
On 15 Jul 2021, at 16:42, Gabriel Cotelli g.cotelli@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
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.
tesonep@gmail.com
You guys are awesome - such a great community.
On 16 Jul 2021, at 12:18, tesonep@gmail.com wrote:
I have updated the VMs, the issue should be resolved now.
On Fri, Jul 16, 2021 at 12:10 PM Guillermo Polito <guillermopolito@gmail.com mailto:guillermopolito@gmail.com> 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 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 <sven@stfx.eu mailto:sven@stfx.eu> escribió:
Anyway, for now, I added guards:
https://github.com/svenvc/zinc/commit/cac2cb36410c24e9070f850b641e0cd02a05deb8 https://github.com/svenvc/zinc/commit/cac2cb36410c24e9070f850b641e0cd02a05deb8
https://github.com/svenvc/zodiac/commit/b12ba07f93ab73afad2523d75149c8b5440b2c64 https://github.com/svenvc/zodiac/commit/b12ba07f93ab73afad2523d75149c8b5440b2c64
but the core problem remains.
On 15 Jul 2021, at 21:35, Gabriel Cotelli <g.cotelli@gmail.com mailto:g.cotelli@gmail.com> 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 <sven@stfx.eu mailto:sven@stfx.eu> wrote:
On 15 Jul 2021, at 16:42, Gabriel Cotelli <g.cotelli@gmail.com mailto:g.cotelli@gmail.com> wrote:
Just doing
NetNameResolver primStartLookupOfName:'unknown-stfx.eu http://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 http://unknown-stfx.eu/'; waitForCompletionUntil: 5
false (signal exception)
Pharo 9
NetNameResolver primStartLookupOfName:'unknown-stfx.eu http://unknown-stfx.eu/'; waitForCompletionUntil: 5
true (bogus 0.0.0.0 result)
On Thu, Jul 15, 2021 at 11:36 AM Sven Van Caekenberghe <sven@stfx.eu mailto:sven@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 http://unknown-stfx.eu/' timeout: 10 ] on: NameLookupFailure do: [ :exception | exception ].
"NameLookupFailure: cannot resolve 'unknown-stfx.eu http://unknown-stfx.eu/'"
Pharo 9:
[ NetNameResolver addressForName: 'unknown-stfx.eu http://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 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 http://unknown-stfx.eu/' timeout: 10.
0.0.0.0
pharo> ZnClient new get: 'http://unknown-stfx.eu http://unknown-stfx.eu/'.
ConnectionTimedOut: Cannot connect to 0.0.0.0:80 http://0.0.0.0/
[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.
tesonep@gmail.com mailto:tesonep@gmail.com
Thank you!
On 16 Jul 2021, at 12:10, Guillermo Polito guillermopolito@gmail.com 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 sven@stfx.eu 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 g.cotelli@gmail.com 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 sven@stfx.eu wrote:
On 15 Jul 2021, at 16:42, Gabriel Cotelli g.cotelli@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 sven@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
thx.
On 16 Jul 2021, at 12:18, tesonep@gmail.com wrote:
I have updated the VMs, the issue should be resolved now.
On Fri, Jul 16, 2021 at 12:10 PM Guillermo Polito guillermopolito@gmail.com 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 sven@stfx.eu 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 g.cotelli@gmail.com 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 sven@stfx.eu wrote:
On 15 Jul 2021, at 16:42, Gabriel Cotelli g.cotelli@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 sven@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
--
Pablo Tesone.
tesonep@gmail.com