Crash while trying to connect to PPTP server
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
network-manager-pptp (Ubuntu) |
Fix Released
|
Undecided
|
Craig Box |
Bug Description
Binary package hint: network-
when I choose the newly added connection to start connecting to the PPTP server Bug Buddy comes up with the attached error message.
Running edgy RC on AMD64 here with latest updates installed. no useful info in /var/log/syslog or dmesg . anywhere else i should have a look.
exactt (giesbert) wrote : | #1 |
Craig Box (craig.box) wrote : | #2 |
onlymee (a-j-mee) wrote : | #3 |
Thanks to Craig for pointing this out to me. Yes, this is precisely the problem I encountered with my colleagues AMD64 Ubuntu Edgy box.
I got as far as determining that it is the gnomeui code behind the gtk_widget_destroy call that causes the crash. That means that if the fault is in the plugin it could be any one of a number of memory allocation related calls. I will have a scan over the most likely bits of the code again to see if I spot anything obvious, but I don't have an AMD64 Edgy box to try this with.
Things to do/Questions to answer:
1) Is this only an AMD64 issue? (I can't reproduce it on my Intel Core Duo)
2) Is this only an Ubuntu issue? And is it only Edgy?
3) Does the version in CVS HEAD work?
The issue can be tested for quite simply without the need to install the plugin or even NetworkManager in full (though most of the dev libs will still be needed to get the plugin to configure). In my tests simply running the auth-dialog tool on it's own was sufficient to see the error.
(This is from memory so please excuse any minor mistakes)
As a normal (non-root) user simply run:
nm-
which on an Ubuntu box is in
/usr/
but may be in
/usr/libexec
on other distros.
The tools requires two options, a NetworkManager DBUS service name and a VPN connection name. Both can be fake as they are only used to to label any information stored in the keyring. So running for example:
/usr/
should display a dialog prompting for the username+password to access "Test Connection".
Enter a username and password and hit OK. Don't tick the session or keyring boxes for a fake connection or else you'll have to go and delete the entries using Keyring manager later! After hitting OK, the dialog should sit there doing nothing. It will be waiting for a carriage return in the terminal (some handshaking method not implemented by me!)where you should also find it has printed out "CHAP" followed by the username and password you entered. Return keyboard focus to the terminal, hit enter and the program should terminate normally.
If the fault occurs it should happen immediately on hitting OK I think.
Maybe I have just found the issue. It seems that despite a call to gtk_widget_hide in the gnome_two_
If building the plugin from source, once built this test may also be performed with the binary in the auth-dialog directory without performin "make install".
Any assistance would be appreciated.
exactt (giesbert) wrote : Re: [Bug 67881] Re: Crash while trying to connect to PPTP server | #4 |
can confirm your test (see below). now trying to compile the latest
version of the applet...
onlymee wrote:
> Thanks to Craig for pointing this out to me. Yes, this is precisely the
> problem I encountered with my colleagues AMD64 Ubuntu Edgy box.
>
> I got as far as determining that it is the gnomeui code behind the
> gtk_widget_destroy call that causes the crash. That means that if the
> fault is in the plugin it could be any one of a number of memory
> allocation related calls. I will have a scan over the most likely bits
> of the code again to see if I spot anything obvious, but I don't have an
> AMD64 Edgy box to try this with.
>
> Things to do/Questions to answer:
> 1) Is this only an AMD64 issue? (I can't reproduce it on my Intel Core Duo)
> 2) Is this only an Ubuntu issue? And is it only Edgy?
> 3) Does the version in CVS HEAD work?
>
> The issue can be tested for quite simply without the need to install the
> plugin or even NetworkManager in full (though most of the dev libs will
> still be needed to get the plugin to configure). In my tests simply
> running the auth-dialog tool on it's own was sufficient to see the
> error.
>
> (This is from memory so please excuse any minor mistakes)
> As a normal (non-root) user simply run:
> nm-ppp-auth-dialog
> which on an Ubuntu box is in
> /usr/lib/
> but may be in
> /usr/libexec
> on other distros.
>
> The tools requires two options, a NetworkManager DBUS service name and a
> VPN connection name. Both can be fake as they are only used to to label
> any information stored in the keyring. So running for example:
>
> /usr/lib/
> org.freedesktop
>
> should display a dialog prompting for the username+password to access
> "Test Connection".
>
> Enter a username and password and hit OK. Don't tick the session or
> keyring boxes for a fake connection or else you'll have to go and delete
> the entries using Keyring manager later! After hitting OK, the dialog
> should sit there doing nothing. It will be waiting for a carriage return
> in the terminal (some handshaking method not implemented by me!)where
> you should also find it has printed out "CHAP" followed by the username
> and password you entered. Return keyboard focus to the terminal, hit
> enter and the program should terminate normally.
>
> If the fault occurs it should happen immediately on hitting OK I think.
it does! on hit hitting "OK" Bug Buddy comes up...
>
> Maybe I have just found the issue. It seems that despite a call to
> gtk_widget_hide in the gnome_two_
> visible after hitting OK on my Intel box. I wonder if it is trying to
> destroy a widget that is currently visible and whether or not that is
> allowed.
>
> If building the plugin from source, once built this test may also be
> performed with the binary in the auth-dialog directory without performin
> "make install".
>
> Any assistance would be appreciated.
>
--
Max Giesbert - exactt technology
Schießstättstr. 16 T: +49 1 77 50 75 3 44
D-80339 München F: +49 89 42 09 55 3 44
exactt (giesbert) wrote : | #5 |
i guess compiling the plugin is a bit too much for me.
or at least compiling the latest networkmanager from cvs.
but feel free to let me test any new packages available.
thx
stefab (bluefuture) wrote : | #6 |
I can also confirm this bug. I have the same connection on i386 and works fine. The crash is only on amd64.
William Hood (william-a-hood) wrote : | #7 |
I can also confirm this. System is AMD64, originally installed as Kubuntu but switched to Ubuntu Desktop. Output of bug buddy is as follows:
Memory status: size: 157569024 vsize: 157569024 resident: 13443072 share: 9125888 rss: 13443072 rss_rlim: -1
CPU usage: start_time: 1168484468 rtime: 40 utime: 35 stime: 5 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100
Backtrace was generated from '/usr/libexec/
(no debugging symbols found)
Using host libthread_db library "/lib/libthread
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 47846418088560 (LWP 5739)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0x00002b841aac3eb5 in waitpid () from /lib/libpthread
#0 0x00002b841aac3eb5 in waitpid () from /lib/libpthread
#1 0x00002b841786aa07 in gnome_gtk_
from /usr/lib64/
#2 <signal handler called>
#3 0x00002b841ac3b86b in free () from /lib/libc.so.6
#4 0x0000000000404c9b in ?? ()
#5 0x00002b841a0dc358 in g_object_unref ()
from /...
exactt (giesbert) wrote : | #8 |
- the automated crash report Edit (790.2 KiB, text/plain)
just testing feisty herd 2 on my amd64 box. and the bug is still there. bug report attached.
exactt (giesbert) wrote : | #9 |
sorry. just realized it's still the same version. a fix would be nice anyway...
stefab (bluefuture) wrote : | #10 |
- hide dialog befor destroy Edit (765 bytes, text/plain)
It's is probably fixed upstream two weeks ago. Anybody can test this patch?
This is for the cvs version:
http://
This apply to the last stable version 0.6.4 but i think that is fully compatible with edgy version 0.6.3+cvs20060819 becuase the diff was against 2006/08/04 version of the mail file:
Changed in network-manager-pptp: | |
status: | Unconfirmed → In Progress |
stefab (bluefuture) wrote : | #11 |
Please, if this patch really works consider also a motu SRU to the last 0.6.4 stable version + patch.
Craig Box (craig.box) wrote : | #12 |
I can have a go at patching and upload the fixed version for testing this week sometime.
If it's worth stepping up a version, I can look at that too, but the trouble I had was that development was happening on the 0.7 branch, which is incompatible with 0.6.x. I'm not sure if there's anything hugely new in CVS, except possibly lots of bugfixes - as good a reason as any to upgrade :)
stefab (bluefuture) wrote : | #13 |
I think that the patch could be applied to edgy and do an upload because actually is not usable on ubuntu 64 bit.
Then if you want to package a cvs version for festy take a look at the svn changelog and talk with upstream developers:
http://
I think that 0.7 will be ready for spring.
edschofield (schofield) wrote : | #14 |
- Valgrind output showing possible cause of the segfault Edit (43.4 KiB, text/plain)
I still get a segfault with this patch. I'm using Feisty AMD-64, network-
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47328421673936 (LWP 30782)]
0x00002b0b7e41022b in free () from /lib/libc.so.6
(gdb) bt
#0 0x00002b0b7e41022b in free () from /lib/libc.so.6
#1 0x0000000000404cfb in gnome_two_
at gnome-two-
#2 0x00002b0b7da9f6a8 in g_object_unref () from /usr/lib/
#3 0x0000000000402fe1 in main (argc=1, argv=0x7fff31bb
Valgrind shows much the same thing; its output is attached.
Gustavo Carneiro (gjc) wrote : | #15 |
gnome-two-
edschofield (schofield) wrote : | #16 |
Gustavo: It's from the source tree of network-
stefab (bluefuture) wrote : | #17 |
Edschofiled could you try to test this patch for the gnome-two-
http://
stefab (bluefuture) wrote : | #18 |
So i think that festy run network-manager 0.6.4 no so i doesn't think that the old pptp plugin network-
edschofield (schofield) wrote : | #19 |
Feisty has the same pptp version as edgy. If it's not compatible with network-manager 0.6.4, does that explain the segfaults?
I tried compiling the 0.6.4-tagged branch from SVN, but I get a linker error: relocation R-X86_64_32 against `a local symbol' ... recompile with -fPIC. Passing --with-pic to ./configure doesn't help. So I'm stumped.
edschofield (schofield) wrote : | #20 |
Some progress: I compiled it with the right CFLAGS. Version 0.6.4 produces a nm-pptp-auth-dialog binary instead of nm-ppp-auth-dialog from the previous version. Was it renamed?
If I run the test given by onlymee earlier in the thread, but with the new filename, I get:
$ /usr/libexec/
This dialog works only with the 'org.freedeskto
Using this instead:
$ /usr/libexec/
outputs the username and password in stdout correctly (no segfault). The program doesn't terminate at all, though -- it keeps the dialog open until I give it Ctrl-C; is this intended?
Executive summary: segfault is gone with the two patches to main.c and gnome-two-
stefab (bluefuture) wrote : | #21 |
I actually think that we need to have more info from onlymee as upstream author.
onlymee (a-j-mee) wrote : | #22 |
Ok ok... I have been listening in but I'm afraid I've been off planet a bit.
New job, new city.
Anyhow. The whole thread strikes me as a little strange. As a couple of you noticed, I found this crash occured on AMD64s and though not owning one myself, a few others helped to iron out that bug. So, a few things I can clarify for you.
1) The renaming from PPTP -> PPP happened long ago and is because the underlying tool is actually a very general general engine for managing a PPP connection. It is only the configuration dialogs which limit the functionality to PPTP.
2) Most of the structure of the plugin comes from those that existed previously (vpnc and openvpn) though a few of the PPTP innovations have gone back the otherway. For example, the not returning behaviour nm-XXXX-auth-dialog is the same in all plugins. It is actually waiting for a carriage return as some kind of STDIN/STDOUT handshake to finish the interaction. Try hitting return instead of Ctrl-C. If it exits normally then you ha
ve the correct behaviour.
3) There is a version issue as to which version of the plugin works with which version of NetworkManager (NM). The difference is related to how the plugin passed the IP configuration of the established connection back to NM. The symptom if that problem is that the connection will establish (eg. monitoring ifconfig/logs) but then NM will timeout because it didn't get a response from the plugin. The truth table looks like this:
NM / Plugin
old / old works
old / new fails
new / old works (but can't set some things like MTU)
new / new works
The plugin can switch behaviour in the source -- grep for NM_VPN_
If you have access to the Ubuntu source package for NM then you can check if you have an old/new NM by doing a grep for "dict" on NetworkManager/
My memory is that the AMD64 crash was ONLY related to the auth-dialog/
What is worrying is that a further patch, added a few months ago, improved the way that nm-ppp-starter handled it's children. A crashing child __should not__ crash nm-ppp-starter anymore, but perhaps that's not the case still on AMD?
onlymee (a-j-mee) wrote : | #23 |
Just read back my previous comment -- my apologies for my use of absolutes in the first paragraph. I am open to the possibility that the issue isn't resolved! :-)
Also, I just fixed the --enable-
edschofield (schofield) wrote : | #24 |
Onlymee: thanks for the info. A clarification: nm-ppp-starter.c doesn't exist in the source tree for version 0.6.4. And by your definition the NM in Feisty is "old": there's no 'dict' in nm-vpn-service.c.
I think we should push Feisty's network-
edschofield (schofield) wrote : | #25 |
I've changed my mind. I now think we should package an SVN version for Feisty. I've compiled the SVN version and I'm impressed. It works for me.
This is a big deal for me. DSL providers in Austria like inode.at *require* PPTP connections for authentication. Without this one gets no access at all. I've spent two days unsuccessfully trying to get a connection with pptp from the command-line and with the older network-
I'm happy to help out with the packaging.
onlymee (a-j-mee) wrote : | #26 |
As I understand, Craig Box's original PPTP package was indeed based on a (slightly patched for Ubuntu) CVS snapshot -- so perhaps using a slightly newer snapshot (now SVN of course) would not be terribly difficult.
stefab (bluefuture) wrote : | #27 |
As nobody seems working on this issue i switch the status from in progress to confirmed.
Changed in network-manager-pptp: | |
status: | In Progress → Confirmed |
johnnymac (jnorden) wrote : | #28 |
Is there a planned fix for this to be added as an upgrade feature? I've hit this as well on my AMD64 and it's a bit annoying.
Mead (ma9mjo) wrote : | #29 |
The bug is still there on Feisty Beta amd64, the workaround posted at the top of this page works fine though.
stefab (bluefuture) wrote : | #30 |
I try to assine to motu-uvf for seek if a new upstream or cvs version has fix this issue
Changed in network-manager-pptp: | |
assignee: | nobody → motu-uvf |
Craig Box (craig.box) wrote : | #31 |
I have a feisty machine to have a look with now. No guarantees at all there'll be a UVF-exception-
Daniel Holbach (dholbach) wrote : | #32 |
Unassigning from motu-uvf. Please read the process documentation and attach all necessary data before: https:/
Changed in network-manager-pptp: | |
assignee: | motu-uvf → nobody |
Matthew Monteleone (mgm-protenus) wrote : | #33 |
I am experiencing the same problem, and the fix works on compaq nx6325 laptop with feisty.
kalyp (kalyp) wrote : | #34 |
Hi everyone,
I am new to Linux and Ubuntu and am experiencing the same problem (Ubuntu 6.10 AMD 64). I read through this page but cannot find the fix you speak about...
Is there a solution to fix this problem? could someone explain what I should do?
Thank you by advance.
edschofield (schofield) wrote : | #35 |
kalyp: I suggest you remove the network-manager and
network-
compile the latest SVN version from source. You'll find instructions
for this online.
Craig Box (craig.box) wrote : | #36 |
If someone can confirm the exact fix (or first revision in SVN where it was fixed) I will try and whip up a newer package this weekend.
stefab (bluefuture) wrote : | #37 |
Craig i think that last stable release network-manager 0.6.5 + vpn plugin have this bug fixed.
stefab (bluefuture) wrote : | #38 |
Probably VPN plugin are not released with the network-manager ftp tarball so u need to checkout http://
Craig Box (craig.box) wrote : | #39 |
I have built a new package for the SVN trunk, which ought to fix this issue. Please feel free to try it: http://
If it works for everyone, I will get it uploaded to the Ubuntu archive for gutsy, and push for an -updates release.
Changed in network-manager-pptp: | |
assignee: | nobody → craig-dubculture |
status: | Confirmed → In Progress |
kalyp (kalyp) wrote : | #40 |
ok thanks for the package!
However, if I understood correctly, there's still nothing available for AMD64 - edgy? no way to fix the AMD64 bug for edgy users?
should I try to install subversion as suggested by edschofield or is it exactly the same thing anyway?
thanks...
Craig Box (craig.box) wrote : | #41 |
Thanks to ajmitch, there's now an AMD64 Edgy package. Please check the link on http://
exactt (giesbert) wrote : | #42 |
i just tested the AMD 64 package provided and it fixes the problem for me.
thx a lot
Craig Box (craig.box) wrote : | #43 |
network-
* New upstream release (fixes LP: #67881, LP: #80541).
* Fix properties dialog so an option is always selected. (fixes LP: #89120)
* Set NoDisplay=true in the .desktop file to hide spurious menu item
(fixes LP: #109856).
* Bump Standards-version to 3.7.2 and fix Maintainer: field in
debian/control.
-- Craig Box <email address hidden> Sun, 4 Jun 2007 11:18:03 +1200
Changed in network-manager-pptp: | |
status: | In Progress → Fix Released |
Please read http:// www.students. ncl.ac. uk/a.j. mee/blog/ index.php/ 2006/11/ 24/networkmanag er-pptp- with-ubuntu- 610-edgy- eft-on- amd64-crash- workaround/ and see if this describes your error, and if the workaround is relevant.