Bug 475864 - nm-openvpn-serv segfaults upon connect
nm-openvpn-serv segfaults upon connect
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: NetworkManager-openvpn (Show other bugs)
10
All Linux
low Severity high
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-10 15:42 EST by Stefan Neufeind
Modified: 2009-11-19 13:53 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-19 13:53:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stefan Neufeind 2008-12-10 15:42:55 EST
trying to create and start a VPN-connection with knetworkmanager.

/var/log/messages says:
Dec 10 21:34:34 machine NetworkManager: <info>  Starting VPN service 'org.freedesktop.NetworkManager.openvpn'...                                                                                                        
Dec 10 21:34:34 machine NetworkManager: <info>  VPN service 'org.freedesktop.NetworkManager.openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 11869
Dec 10 21:34:34 machine NetworkManager: <info>  VPN service 'org.freedesktop.NetworkManager.openvpn' just appeared, activating connections
Dec 10 21:34:34 machine kernel: nm-openvpn-serv[11869]: segfault at 0 ip 00000000004023e1 sp 00007fff738b4e00 error 4 in nm-openvpn-service[400000+5000]
Dec 10 21:34:34 machine NetworkManager: <info>  VPN plugin state changed: 1
Dec 10 21:34:34 machine NetworkManager: <WARN>  vpn_service_watch_cb(): VPN service 'org.freedesktop.NetworkManager.openvpn' died with signal 11
Dec 10 21:34:34 machine NetworkManager: <WARN>  connection_state_changed(): The name org.freedesktop.NetworkManager.openvpn was not provided by any .service files
Dec 10 21:34:34 machine NetworkManager: <info>  Policy set 'dhcp-default' (eth0) as default for routing andDNS.
Dec 10 21:34:34 machine NetworkManager: <info>  VPN service 'org.freedesktop.NetworkManager.openvpn' disappeared, cancelling connections
Comment 2 Christoph Höger 2009-01-28 02:38:01 EST
Hi,

sorry for the delay, but this bug must have been lost on my schedule due to the holidays.

As far as I can see there must be some different place of a segfault.

What (vpn) setup do you use?

Could you please
a) try to reproduce the bug 
b) install debuginfo packages, hook onto nm-openvpn-servcice with gdb and provide a stacktrace (just in case I can not reproduce it with my limited amount of vpn setups)

thanks
Comment 3 Stefan Neufeind 2009-01-28 03:35:35 EST
a) still reproducable

b) How would I? nm-openvpn-serv is branched from the running NetworkManager. I tried attaching to NetworkManager, then starting the OpenVPN-connection. gdb seemed to notice the forks, however did not jump back to the shell after nm-openvpn-serv segfaulted, so I could "bt" there. Any hint how to do that?
Comment 4 Christoph Höger 2009-01-28 03:58:45 EST
a) ok, which setup?

b) basically you should setup a trap by replacing the binary (moving it - not deleting!) with a script (named nm-openvpn-serv) that runs gdb in batch mode (see man page -batch option), which is then ordered to start the original binary and do a bt after it exits. Note that I did not do that yet with gdb, so I cannot say how to do it exactly but it should be straight forward.

thanks for your help
Comment 5 Stefan Neufeind 2009-01-28 04:22:24 EST
hah, even easier. Make sure no nm-openvpn-serv runs, start one in gdb (gdb gdb /usr/libexec/nm-openvpn-service) then "run", connect to VPN, then "bt". Output attached. (Thanks to Dan Williams' posting archived at http://www.nabble.com/Broken-OpenVPN-td18783165.html)


Program received signal SIGSEGV, Segmentation fault.
0x00000000004023e1 in real_need_secrets (plugin=<value optimized out>, connection=0x609440,
    setting_name=0x7fffffffde30, error=0x7fffffffde28) at nm-openvpn-service.c:936
936             if (!strcmp (connection_type, NM_OPENVPN_CONTYPE_PASSWORD_TLS)) {
(gdb)
(gdb)
(gdb) bt
#0  0x00000000004023e1 in real_need_secrets (plugin=<value optimized out>, connection=0x609440,
    setting_name=0x7fffffffde30, error=0x7fffffffde28) at nm-openvpn-service.c:936
#1  0x0000003a01c02680 in impl_vpn_plugin_need_secrets (plugin=0x6108a0, properties=0x609280,
    setting_name=0x613420, err=0x7fffffffe290) at nm-vpn-plugin.c:416
#2  0x0000003a01c03df3 in dbus_glib_marshal_nm_vpn_plugin_BOOLEAN__BOXED_POINTER_POINTER (closure=0x7fffffffe160,
    return_value=0x7fffffffe240, n_param_values=<value optimized out>, param_values=0x616480,
    invocation_hint=<value optimized out>, marshal_data=0x3a01c025a0) at nm-vpn-plugin-glue.h:143
#3  0x0000003a0380c878 in invoke_object_method () at dbus-gobject.c:1282
#4  gobject_message_function (connection=0x612d70, message=0x613240, user_data=<value optimized out>)
    at dbus-gobject.c:1424
#5  0x000000366541c561 in _dbus_object_tree_dispatch_and_unlock (tree=0x612a30, message=0x613240)
    at dbus-object-tree.c:856
#6  0x000000366540efd6 in dbus_connection_dispatch (connection=0x612d70) at dbus-connection.c:4447
#7  0x0000003a03809765 in message_queue_dispatch (source=<value optimized out>, callback=<value optimized out>,
    user_data=<value optimized out>) at dbus-gmain.c:101
#8  0x00000039fde3779b in g_main_dispatch () at gmain.c:2144
#9  IA__g_main_context_dispatch (context=0x614950) at gmain.c:2697
#10 0x00000039fde3af6d in g_main_context_iterate (context=0x614950, block=1, dispatch=1,
    self=<value optimized out>) at gmain.c:2778
#11 0x00000039fde3b49d in IA__g_main_loop_run (loop=0x612170) at gmain.c:2986
#12 0x000000000040205b in main (argc=<value optimized out>, argv=<value optimized out>)
    at nm-openvpn-service.c:1075
Comment 6 Christoph Höger 2009-01-28 05:02:06 EST
Ah yes, that helps alot. If you have the time, could you please inspect the local var tmp just before that segfault? Would be nice to see what's returned by  

nm_setting_vpn_get_data_item (s_vpn, NM_OPENVPN_KEY_CONNECTION_TYPE);

looks like you do not have a valid connection type set.
Comment 7 Dan Williams 2009-01-28 12:28:48 EST
Any chance we can figure out what the connection type might be?  There's a bunch of code in the applet to convert older types to newer types.  It'll be in GConf in /system/networking/connections/<a number>/vpn/ .
Comment 8 Dan Williams 2009-01-28 12:40:15 EST
Patch committed upstream:

trunk: svn r16
stable: svn r17
Comment 9 Christoph Höger 2009-01-28 14:55:28 EST
I had a email discussion with Stefan during the day while trying to figure out via gdb what value that tmp var really has. Unfortunately I could not reproduce it and on Stefans machine (a 64bit architecture) it seems that the tmp var is optimized out of code (which means we could not look into it via debugger, as the responding function call relies on macros).
Comment 10 Stefan Neufeind 2009-01-31 11:01:00 EST
It definitvely seems to be related to knetworkmanager-openvpn interacting with the NetworkManager-core. Using the openvpn-dialog of the gnome-networkmanager-applet (either running under Gnome or even using it under KDE!) works fine.

Trying to find out what "type" is used Christoph suggested to have a look at the gconf-entries. But the knetworkmanager-applet doesn't seem to store it's network-connections there.

PS: From an error-message in /var/log/message I later found out that they might be stored under /org/freedesktop/NetworkManagerSettings/Connection/1 ...
Comment 11 Bug Zapper 2009-11-18 04:39:49 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 12 Dan Williams 2009-11-18 15:31:01 EST
Is this still an issue with F11's openvpn updates from July, if anyone here has upgraded to F11?
Comment 13 Stefan Neufeind 2009-11-18 18:47:45 EST
sorry, can't test again on my side since meanwhile I've upgraded to F12 and don't use openvpn yet for the moment (so even can't shortly retest against F12)
Comment 14 Dan Williams 2009-11-19 13:53:17 EST
Ok, please re-open if you see this in F12 as well.  Thanks!

Note You need to log in before you can comment on or make changes to this bug.