rosgraph exception starting roscore

[adamantivm]

Apologies if this is a user error and doesn't belong here.

On a freshly installed bare ROS groovy, I can't start roscore: I get the following exception:

Traceback (most recent call last):
  File "/opt/ros/groovy/lib/python2.7/dist-packages/roslaunch/__init__.py", line 263, in main
    p.start()
  File "/opt/ros/groovy/lib/python2.7/dist-packages/roslaunch/parent.py", line 268, in start
    self.runner.launch()
  File "/opt/ros/groovy/lib/python2.7/dist-packages/roslaunch/launch.py", line 644, in launch
    self._setup()
  File "/opt/ros/groovy/lib/python2.7/dist-packages/roslaunch/launch.py", line 620, in _setup
    self._launch_master()
  File "/opt/ros/groovy/lib/python2.7/dist-packages/roslaunch/launch.py", line 384, in _launch_master
    validate_master_launch(m, self.is_core, self.is_rostest)
  File "/opt/ros/groovy/lib/python2.7/dist-packages/roslaunch/launch.py", line 79, in validate_master_launch
    if not rosgraph.network.is_local_address(m.get_host()):
  File "/opt/ros/groovy/lib/python2.7/dist-packages/rosgraph/network.py", line 160, in is_local_address
    local_addresses = ['localhost'] + get_local_addresses()
  File "/opt/ros/groovy/lib/python2.7/dist-packages/rosgraph/network.py", line 211, in get_local_addresses
    ifaces = ifaddrs.getifaddrs()
  File "/opt/ros/groovy/lib/python2.7/dist-packages/rosgraph/ifaddrs.py", line 116, in getifaddrs
    sa = sockaddr.from_address(ifa.ifa_addr)
TypeError: integer expected

In case it is of any use, here is my network configuration:

box:~/moveit_groovy$ ifconfig
eth0      Link encap:Ethernet  HWaddr 80:ee:73:12:6e:7a  
          inet addr:10.1.0.10  Bcast:10.1.255.255  Mask:255.255.0.0
          inet6 addr: fe80::82ee:73ff:fe12:6e7a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:189757 errors:0 dropped:0 overruns:0 frame:0
          TX packets:173295 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:186011640 (186.0 MB)  TX bytes:14740247 (14.7 MB)
          Interrupt:63 Base address:0xe000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1787 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1787 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:241486 (241.4 KB)  TX bytes:241486 (241.4 KB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.0.10.237  P-t-P:10.0.10.238  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:5545 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4872 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:6712642 (6.7 MB)  TX bytes:279550 (279.5 KB)

Any hints? If it is indeed a bug, how could I help fix it?

[adamantivm]

Some additional information about this: after adding some print statements it became evident that it is failing with the VPN interface (tun0) where the value of ifa.ifa_addr is None.

The following patch adds a workaround to avoid crashing, but probably prevents the interface from working with ros:

112a113,115
>       if ifa.ifa_addr is None:
>           continue
> 

[schneider42]

Hi Julian,

I will investigate into this tomorrow.

Thanks for the bug report,
Tobias

On Di, 2012-12-04 at 11:12 -0800, Julian Cerruti wrote:

Some additional information about this: after adding some print
statements it became evident that it is failing with the VPN interface
(tun0) where the value of ifa.ifa_addr is None.

The following patch adds a workaround to avoid crashing, but probably
prevents the interface from working with ros:

112a113,115

  if ifa.ifa_addr is None:
      continue

—
Reply to this email directly or view it on GitHub.

[adamantivm]

Thank you Tobias.

I forgot to add that unfortunately that workaround didn't solve the issue:
it makes roscore hang forever. The only workaround (not very practical) for
now was to bring down the VPN, start whatever ROS process I need to start,
then bring the VPN back up.

On Tue, Dec 4, 2012 at 6:27 PM, schneider42 notifications@github.comwrote:

Hi Julian,

I will investigate into this tomorrow.

Thanks for the bug report,
Tobias

On Di, 2012-12-04 at 11:12 -0800, Julian Cerruti wrote:

Some additional information about this: after adding some print
statements it became evident that it is failing with the VPN interface
(tun0) where the value of ifa.ifa_addr is None.

The following patch adds a workaround to avoid crashing, but probably
prevents the interface from working with ros:

112a113,115

if ifa.ifa_addr is None:
continue

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/30#issuecomment-11016422.

[schneider42]

@adamantivm: This should fix your problem. tun devices seem to pollute the return values of getifaddrs. Your approach was circumventing an error, but created an endless loop checking the same entry over and over again.
@dirk-thomas I've filed a corresponding pull request.

[adamantivm]

Thank you. I can confirm this fix.