[Bug 652961] Re: vino-server won't start (SIGSEGV) when UPnP is enabled (SRU)

[tombert]

Did an update for Desktop 10.10 today ... still having the signal 11 ...
As a workaround it helps to start the application twice - then it works.

-- 
vino-server won't start (SIGSEGV) when UPnP is enabled (SRU)
https://bugs.launchpad.net/bugs/652961
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is a direct subscriber.

Status in “vino” package in Ubuntu: Triaged

Bug description:
Binary package hint: vino

This is the SRU fix for the natty bug #663270.

vino won't start if you have UPnP enabled on at least some routers. This causes many users default remote desktop service to never start.


Test Case:
1) enable UPnP on your router

2)
$ /usr/lib/vino/vino-server
14/10/2010 07:47:39 PM Autoprobing TCP port in (all) network interface
14/10/2010 07:47:39 PM Listening IPv6://[::]:5900
14/10/2010 07:47:39 PM Listening IPv4://0.0.0.0:5900
14/10/2010 07:47:39 PM Autoprobing selected port 5900
14/10/2010 07:47:39 PM Advertising security type: 'TLS' (18)
14/10/2010 07:47:39 PM Advertising authentication type: 'VNC Authentication' (2)
14/10/2010 07:47:39 PM Advertising security type: 'VNC Authentication' (2)
** Message: Received signal 11, exiting...

Backtrace:
Thread 1 (Thread 0xb7fdba70 (LWP 5169)):
#0 0x00c34370 in __nss_hostname_digits_dots () from /lib/libc.so.6
#1 0x00c38cca in gethostbyname () from /lib/libc.so.6
#2 0x0807a5c2 in miniwget2 (url=<value optimized out>, host=0x0, port=2555, path=0x811f18b "/upnp/6c352473-8521-319e-8757-639e9dca9979/desc.xml", size=0xbfffefac, addr_str=0x80c0c58 "", addr_str_len=16) at miniwget.c:45
#3 0x0807a9b1 in miniwget_getaddr (url=0x811f174 "http://192.168.1.1:2555/upnp/6c352473-8521-319e-8757-639e9dca9979/desc.xml", size=0xbfffefac, addr=0x80c0c58 "", addrlen=16) at miniwget.c:223
#4 0x08079c53 in UPNP_GetValidIGD (devlist=0x811f168, urls=0x81104a8, data=0x811f1f8, lanaddr=0x80c0c58 "", lanaddrlen=16) at miniupnpc.c:676
#5 0x0805ce1d in update_upnp_status (upnp=0x80c0c40) at vino-upnp.c:96
#6 0x0805d0b7 in vino_upnp_add_port (upnp=0x80c0c40, port=5900) at vino-upnp.c:229
#7 0x08056d63 in vino_server_control_upnp (server=0x8108600) at vino-server.c:254
#8 0x08058208 in vino_server_set_use_upnp (server=0x8108600, use_upnp=1) at vino-server.c:275
#9 0x00a1d995 in ?? () from /usr/lib/libgobject-2.0.so.0
#10 0x00a1b86a in g_object_newv () from /usr/lib/libgobject-2.0.so.0
#11 0x00a1c3cc in g_object_new_valist () from /usr/lib/libgobject-2.0.so.0
#12 0x00a1c4e7 in g_object_new () from /usr/lib/libgobject-2.0.so.0
#13 0x08055dbf in vino_prefs_create_server (screen=0x80be0c8) at vino-prefs.c:517
#14 0x08054557 in main (argc=1, argv=0xbffff4a4) at vino-main.c:117

Solution:
Debian added a patch to fix a FTBFS on hurd. The patch worked well in the 2.28 branch, but breaks the UPnP support in 2.32. The fix, for Ubuntu, is to remove the patch since ubuntu doesn't release for hurd. See patch below.

Regression potential:
Very little - the patch that I removed was not written for the 2.32 branch, and we are reverting to pristine upstream UPnP code. We are losing build support for hurd. We don't build hurd, so there shouldn't be a problem.