Sat 14 May 2016 02:35:03 PM UTC, comment #5:
I have tested several programs regarding the behavior on connecting to dual-stack TCP server on localhost. (Dual-stack in this case means host name lookup returns both IPv4 and IPv6 address)
If the server listened with IPv4 (ordinary AF_INET) socket, an attempt to connect to server's IPv6 address will fail ("Connection refused") while IPv4 succeeds. But if the server listened with IPv6 (AF_INET6) socket, an attempt to connect to server's IPv4 or IPv6 address would succeed.
For current Gnash's behavior:
- Gnash HTTP (via libcurl): connects IPv6 first. If fails, tries IPv4.
- Gnash FTP (via libcurl): connects IPv6 first. If fails, tries IPv4.
- Gnash RTMP (via libcurl): connects IPv6 first. If fails, tries IPv4.
- Gnash XMLSocket: connects IPv6 only.
Wget: 1.13.4 (debian)
Iceweasel: 10.0.12 (debian)
Curl: 7.26.0 (debian)
Netcat: 1.10-40 (debian)
Gnash: 0.8.11dev (git c6da486 10-May-2016)
System: Debian GNU/Linux 7.0 Wheezy i386
|
Thu 12 May 2016 04:21:21 PM UTC, comment #4:
For the test failure itself, according to IP address part of test output:
It seems that Gnash looked up "localhost" and found two IP address (IPv4 and IPv6, per my default `/etc/hosts`). The output didn't tell which one Gnash tried to connect. So I tried following command (as root):
to disable IPv6 and run the test again. This time the test ended quickly (~3 sec) and result is now passing:
This narrows Gnash's part of this issue to how it deals with a dual-stack TCP server.
Note: at the end of this test run, there was no lurking server process in the background.
Gnash: Gnash 0.8.11dev (git c6da486 10-May-2016)
System: Debian GNU/Linux 7.0 Wheezy i386
|
Thu 12 May 2016 02:35:39 PM UTC, comment #3:
The patch mentioned in previous post is file #37142, the file number was misquoted, sorry.
|
Thu 12 May 2016 02:33:17 PM UTC, comment #2:
After I patched XmlSocketServer to use normal `IO::Socket::INET` as a fallback (using the attached `0001_xmlsocketserver-perl-inet6-optional.patch` file #37140), the XMLSocketTester does not produce Perl error anymore, but the test is still failing:
After the test ended, the server process (`testsuite/XmlSocketServer.pl`) is still lurking behind, and could be connected to using `nc localhost 2229` command (and also can be terminated by typing "closeNow" followed by Enter on netcat's console).
I think the test runner should force kill the server at the end of test (in case ActionScript side failed to request server to terminate). Otherwise it would interfere with the later test run.
Gnash: Gnash 0.8.11dev (git c6da486 10-May-2016)
System: Debian GNU/Linux 7.0 Wheezy i386
|
Thu 12 May 2016 01:59:53 PM UTC, comment #1:
I have tried running the XMLSocketTester test in isolation (in `testsuite/misc-ming.all` folder). The test ended with following output:
It turned out that XmlSocketServer script tries to import `IO::Socket::INET6` Perl module, which is not a core module; and not available unless user installed a separate `libio-socket-inet6-perl` package.
My system didn't have it installed, so the script just simply error out and terminated, leaving ActionScript side of the test trying to connect a nonexistent server, thus produced test failure.
In any case, XmlSocketServer script shouldn't fail from just a lack of optional IPv6 module while the standard IPv4 one (`IO::Socket::INET` core module) is still available. This could be fixed with few changes to the `use` statement.
Gnash: Gnash 0.8.11dev (git c6da486 10-May-2016)
System: Debian GNU/Linux 7.0 Wheezy i386
|
Thu 12 May 2016 01:38:00 PM UTC, original submission:
This is a follow-up to bug #45840 comment 8.
It bugs me for a while, that every time I run Gnash testsuite (`make check`) on my machine, the ActionScript XMLSocket test would always fail due to some unknown reason:
This problem might not be reproducible on every system.
Configuration, build, and test run log are attached as `xmlsockettest.c6da486.zip`.
Gnash: Gnash 0.8.11dev (git c6da486 10-May-2016)
System: Debian GNU/Linux 7.0 Wheezy i386
|