bug mentioned on other sites:
https://bugs.launchpad.net/ubuntu/+source/knetworkmanager/+bug/275111
https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/282404
http://forum.kde.org/knetworkmanager-openvpn-failed-on-kde-3-and-4-t-6577.html

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

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?

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

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

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.

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

Patch committed upstream:

trunk: svn r16
stable: svn r17

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

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

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

Is this still an issue with F11's openvpn updates from July, if anyone here has upgraded to F11?

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)

Ok, please re-open if you see this in F12 as well.  Thanks!