Red Hat Bugzilla – Bug 187069
Crash on start-up when VPNC running
Last modified: 2007-11-30 17:11:28 EST
Description of problem: When VPNC is running, Xvnc crashes on start-up. It's something to do with the 'tun0' interface. Version-Release number of selected component (if applicable): vnc-server-4.1.1-36 How reproducible: 100% Steps to Reproduce: 1. Start vpnc 2. Xvnc :2 Actual results: [tim@cyberelk ~]$ /sbin/ifconfig tun0 tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:172.16.83.149 P-t-P:172.16.83.149 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1412 Metric:1 RX packets:758 errors:0 dropped:0 overruns:0 frame:0 TX packets:935 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:268878 (262.5 KiB) TX bytes:70967 (69.3 KiB) [tim@cyberelk ~]$ gdb --args Xvnc :2 GNU gdb Red Hat Linux (6.3.0.0-1.122rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db library "/lib64/libthread_db.so.1". (gdb) r Starting program: /usr/bin/Xvnc :2 Program received signal SIGSEGV, Segmentation fault. ConvertAddr (saddr=0x0, len=0x7fffff9b44ec, addr=0x7fffff9b44d8) at access.c:1861 1861 switch (saddr->sa_family) (gdb) up #1 0x0000000000519aa8 in DefineSelf (fd=Variable "fd" is not available. ) at access.c:983 983 family = ConvertAddr(ifr->ifa_addr, &len, (pointer *)&addr); (gdb) p *ifr $1 = {ifa_next = 0x7aac40, ifa_name = 0x7aac2c "tun0", ifa_flags = 4305, ifa_addr = 0x0, ifa_netmask = 0x0, ifa_ifu = {ifu_broadaddr = 0x0, ifu_dstaddr = 0x0}, ifa_data = 0x7ab210} (gdb) bt #0 ConvertAddr (saddr=0x0, len=0x7fffff9b44ec, addr=0x7fffff9b44d8) at access.c:1861 #1 0x0000000000519aa8 in DefineSelf (fd=Variable "fd" is not available. ) at access.c:983 #2 0x000000000051bb73 in CreateWellKnownSockets () at connection.c:432 #3 0x0000000000436590 in main (argc=2, argv=0x7fffff9b46e8, envp=0x7fffff9b4700) at main.c:318 #4 0x000000376d71d084 in __libc_start_main () from /lib64/libc.so.6 #5 0x00000000004159f9 in _start () #6 0x00007fffff9b46d8 in ?? () #7 0x0000000000000000 in ?? ()
I am having the same problem. This also occurs when using openvpn (from extras).
I see this conflict with opevpn as well. The specific symptom is that getifaddrs() returns a set of interfaces within which the "tun0" entry has a null "ifa_addr" pointer. There are 3 possible places where the real bug may lie: [1] In VNC's unix/xorg-server-1.0.1/os/access.c:DefineSelf()'s failure to handle this case, if it is normal; [2] In getifaddrs() having dared to return such a null pointer, if it is not normal (in which case, this is actually a glibc bug?); or [3] In the kernel's tun.c tunnel driver, if it failed to fill in returned structures properly when queried for data about tun0. I don't have time to dive deeply into this, but a simple-minded fix for the first case is this (from the -36 source RPM): --- unix/xorg-server-1.0.1/os/access.c~ 2005-11-08 01:33:30.000000000 -0500 +++ unix/xorg-server-1.0.1/os/access.c 2006-04-26 20:58:33.000000000 -0400 @@ -980,7 +980,9 @@ continue; #endif /* DNETCONN */ len = sizeof(*(ifr->ifa_addr)); - family = ConvertAddr(ifr->ifa_addr, &len, (pointer *)&addr); + family = (ifr->ifa_addr ? + ConvertAddr(ifr->ifa_addr, &len, (pointer *)&addr) + : -1); if (family == -1 || family == FamilyLocal) continue; #if defined(IPv6) && defined(AF_INET6) This works, but my suspicion is that the real problem is in getifaddrs(). It seems to me that it is unreasonable to be returned a list of active interfaces which fail to contain valid pointers to addressing structures.
I was trying to find out, what the reason of the NULL pointer was. Whatever it was -- if it is really a bug (to return NULL in this case), I believe we will soon find out.
The problem now should be fixed in version 4.1.1-38.
*** Bug 187607 has been marked as a duplicate of this bug. ***