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

Kamil Ślepowroński 652961 at bugs.launchpad.net
Tue Oct 19 22:12:41 BST 2010


I can confirm that new package works fine for me.

Before even disabling uPnP on all 3 routers was not enought to make it
working.

-- 
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.





More information about the Ubuntu-sponsors mailing list