SocketListener warnings in Travis log when using Arduino IDE 1.8.2
Opened this issue · 9 comments
Use of install_package or build_sketch functions with Arduino IDE 1.8.2 causes many SocketListener warnings such as:
[SocketListener(testing-gce-b31aaad6-3573-4af8-8ea4-e547cb17aa6f-c-travis-ci-prod-5-internal.local.)] WARN javax.jmdns.impl.DNSIncoming$MessageInputStream - bad domain name: possible circular name detected. Bad offset: 0x3fff at 0x72
as well as other undesirable output.
For example:
https://travis-ci.org/per1234/arduino-ci-script/builds/223366084#L358
and
https://travis-ci.org/per1234/arduino-ci-script/builds/223366084#L1039
This also occurs with the hourly build of the Arduino IDE:
https://travis-ci.org/per1234/misc/builds/220508986#L188
It does not occur with Arduino IDE 1.8.1 or older:
https://travis-ci.org/per1234/arduino-ci-script/builds/223366084#L1020
It does occur with Arduino IDE 1.9.0 beta build 31:
https://travis-ci.org/per1234/misc/builds/325452271
The undesirable output (along with desirable output) does not appear when stderr from the verification is redirected to /dev/null:
https://travis-ci.org/per1234/misc/builds/412440730
This does not affect the build success but it makes it very difficult to read the log.
The ideal solution is to find a way to configure the Travis CI environment so this output is not produced.
The workaround solution is to filter the undesirable lines from the output. This has the potential for false positives.
UPDATE: Workaround completed in bc7f89a
If future versions of the Arduino IDE can be modified to avoid the creation of this output that would be nice but it will not solve this issue since the output will still occur with the previously released versions that will be used for testing backwards compatibility.
Arduino forum thread:
http://forum.arduino.cc/index.php?topic=469428
Somewhat related: arduino/Arduino#7388
I ran into a similar problem. It appeared when I added sudo apt-get install libc6-i386 on 64-bit Ubuntu (trusty) under Travis to test our library with a new BSP. Reverting the change also cleared up the unwanted output. The problem, of course, is that there are some 32-bit-only tools in the BSP in question (in particular, STM32 dfu-suffix in this BSP is not shipped in 64-bit form). Luckily, i could use a --pref option to disable use of this 32-bit tool when doing CI. (It's always called at the end of a build.)
I could not find anything your scripts or test files that was installing libc-i386; so this might be irrelevant. Nevertheless, the messages were identical. Note that the query appears to be looking for names containing 'travis'. It's possible that this is a travis setup problem.
@terrillmoore thanks for your information!
I did some more tests and am even more confused than ever. Using identical configurations in two different repos, one has warnings, the other doesn't.
It seems like the warnings may be related to using symlinks but it's extremely difficult to investigate this with these inconsistent results.
The fact this problem doesn't always occur (as I had previously thought) gives me hope that it's possible to find a real solution to this problem but, for now, it's beyond me.
Hmm. strange, this problem resurfaced today. No changes on my part. I am not sure what's happening, but it may be related to the recent migration of the referenced repos from travis-ci.org to travis-ci.com. This both slows down my builds and causes extra messages (seems to be one message per compile step).
This is happening with 1.8.5 and 1.8.7 IDEs. It's no longer conditional on which BSP I use.
Since this is coming from the JDK, it seems like there must be some kind of a setting problem or environment problem.
Well, I can guess what's happening. jmdns implements bonjour, so it's listening for broadcasts. TravisCI is not running our tests in a stand-alone environment. My guess is that some other process(es) in the same compute cluster are sending bonjour notifications, triggering the messages. There's probably nothing we can do about it. This would explain the randomness. Seems unlikely that this would have anything to do with symlinks.
I have no idea if it's possible to run IPFW on Travis VMs or if they'd be effective. But maybe this should be brought up with Travis tech support? It's likely something they can fix.
Thanks for your comment terrillmoore. I also have thought that this might be something only Travis CI can fix, since it doesn't seem like Arduino thinks they can do anything. The problem for me is that I am reluctant to report bugs that I don't have a fairly good understanding of. I've found that, all too often, developers take the attitude of "user error unless overwhelming proof is given to the contrary" and I am required to provide a rigorous defense of my bug reports to get them taken seriously, even when I thought I had made the issue quite clear from the start. In this case, I don't feel I have good footing for such a defense.
I can confirm that firewalling stops the annoying messages :-)
# steps to do before the install
before_install:
# download the Arduino IDE, use HTTPS
- wget https://downloads.arduino.cc/arduino-$ARDUINO_VERSION_TO_USE-linux64.tar.xz
# unpack it
- tar xf arduino-$ARDUINO_VERSION_TO_USE-linux64.tar.xz
# move the unpacked items to a better location
- sudo mv arduino-$ARDUINO_VERSION_TO_USE /usr/local/share/arduino
# add the arduino directory so executables are also considered/searched for in that arduino-subfolder
- export PATH=$PATH:/usr/local/share/arduino
# Arduino IDE adds a lot of noise caused by network traffic, trying to firewall it off
- sudo iptables -P INPUT DROP
- sudo iptables -P FORWARD DROP
- sudo iptables -P OUTPUT ACCEPT
- sudo iptables -A INPUT -i lo -j ACCEPT
- sudo iptables -A OUTPUT -o lo -j ACCEPT
- sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
I think I know what the root cause is -- the IDE is checking for updates and this destructively interferes with the VM/Docker config on Travis. If the Arduino IDE people could have a switch to disable checks for updates, that would simplify things (and probably make builds faster too, as there's no need to check for updates during CI testing). The firewall hack is a nice one, thanks @Torxgewinde.
Oh so happy, thank you @Torxgewinde . I was struggling to read the CI logs. Also thanks for @per1234 for dealing with the issue in the first place.