The Fedora pptp package already has most of the changes from upstream cvs, with the exception of a couple of changes adding new functionality. Getting a backtrace of one of these crashes would be useful if you could do it.

Here is the backtrace(I only made the pptp ip and host name unreadable):

# gdb /usr/sbin/pptp core.13323 
GNU gdb (GDB) Fedora (7.3.50.20110722-9.fc16)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/sbin/pptp...Reading symbols from /usr/lib/debug/usr/sbin/pptp.debug...done.
done.

warning: core file may not match specified executable file.
[New LWP 13323]
Missing separate debuginfo for 
Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/db/8dfab1cb00f1914573d3aa11e942b2d2a9b946
Core was generated by `pptp xxxx.xxxxxx.xxx --nolaunchpppd --loglevel 0 --logstring vpn_ppp9'.
Program terminated with signal 11, Segmentation fault.
#0  0x0804e796 in binary_search (key=29712, v=<optimized out>) at vector.c:149
149             if (key <  v->item[x].key) r = x - 1; else l = x + 1;
(gdb) thread apply all bt full

Thread 1 (LWP 13323):
#0  0x0804e796 in binary_search (key=29712, v=<optimized out>) at vector.c:149
        l = <optimized out>
        r = 13923351
        x = 6961675
#1  0x0804e9ba in vector_contains (v=0x9e78560, key=29712) at vector.c:138
        __PRETTY_FUNCTION__ = "vector_contains"
#2  0x0804bda4 in pptp_call_destroy (conn=0x9e784a0, call=0x9e78978) at pptp_ctrl.c:410
        __PRETTY_FUNCTION__ = "pptp_call_destroy"
#3  0x0804bea9 in pptp_conn_destroy (conn=0x9e784a0) at pptp_ctrl.c:449
        i = 0
        __PRETTY_FUNCTION__ = "pptp_conn_destroy"
#4  0x08050ee3 in callmgr_main (argc=3, argv=0xbf81fe60, envp=0xbf8211f4) at pptp_callmgr.c:297
        rc = <optimized out>
        read_set = {__fds_bits = {0 <repeats 32 times>}}
        write_set = {__fds_bits = {0 <repeats 32 times>}}
        tv = {tv_sec = 0, tv_usec = 0}
        inetaddr = {s_addr = 47496396}
        inet_sock = 0
        unix_sock = 1
        call_set = {__fds_bits = {0 <repeats 32 times>}}
        conn = 0x9e784a0
        call_list = 0x9e7a688
        max_fd = 6
        first = 0
        retval = <optimized out>
        i = <optimized out>
        phonenr = 0x0
        __FUNCTION__ = "callmgr_main"
        __PRETTY_FUNCTION__ = "callmgr_main"
#5  0x0804a312 in launch_callmgr (inetaddr=..., phonenr=0x0, argc=7, argv=0xbf8211d4, envp=0xbf8211f4) at pptp.c:505
        my_argv = {0xbf82296f "pptp", 0xb77c56a0 "xxx.xxx.xxx.x", 0x0}
        buf = "pptp: call manager for xxx.xxx.xxx.x\000z\324\000\001\000\000\000IM\301\000\364o\324\000\230\210\324\000\000\000\000\000\370\376\201\277Wz\305\000\034\207\004\bhf\005\b\334\376\201\277\000\000\000\000\376\063\000\000\300V|\267\240\376\201\277\000\000\000\000\062\065\065.\001\000\000\000>\377\201\277\364o\324\000\324\021\202\277\220?\000\v", <incomplete sequence \305>
        rc = <optimized out>
#6  0x0804a4c4 in open_callmgr (inetaddr=..., phonenr=0x0, argc=7, argv=0xbf8211d4, envp=0xbf8211f4, pty_fd=0, gre_fd=4)
    at pptp.c:474
        where = {sun_family = 1, 
---Type <return> to continue, or q <return> to quit---
          sun_path = "/var/run/pptp/255.255.255.255:xxx.xxx.xxx.x\000\260\254\004\b\004\000\000\000\234\377\201\277\020\000\000\000\000\000\000\000\034\207\004\bxe\005\b(\021\202\277|\241\004\bt)\202\277\310b\272\000\a\000\000\000\002\000\000\000?\324\002\324\021\202\277\a\000\000"}
        fd = 1
        pid = <optimized out>
        status = 4
        __FUNCTION__ = "open_callmgr"
#7  0x08049720 in main (argc=Cannot access memory at address 0x7410
) at pptp.c:375
        inetaddr = {s_addr = 47496396}
        callmgr_sock = -1
        ttydev = '\000' <repeats 2113 times>, "?\224", '\000' <repeats 45 times>, "x\006}\267(\t\202\277d\225\000\b\v\202\277\200\347\223\000\000\200\324\000\\*\000\000\003\000\000\000\062\000\000\000\377\377\377\377\000\000\000\000\000\000\000\000\330\003}\267X\t\202\277d\225\000\330\003}\267\367\341\223\000x\340r\000\000\000\000\000\b\000\000\000\200?\000\000\000\000\000\000P\032\000\070N\032\000\070N\032\000\000\000\000\000\005\000\000\000\000P\032\000\000\200\032\000|~\032\000\\\252\032\000\000P\032\000\003\000\000\000\b\000\000\000r\002\000\000\240\030\000\000\240\030\000\000d\225\000x\006}\267T\232\225\000\243?\000\b\000\000\000\017\000\000\000\000\020\000\000\003\000\000\000d\225\000\000\000\000\000d\225\000\340,\224\000\360\b}\267h\006}\267\017\000\000\000\000\000\000\000d\225\000\000\000\000\000/\b}\267\325)\224\000?\225\000h\006}\267\022"...
        tty_name = <optimized out>
        pty_fd = 0
        tty_fd = 0
        gre_fd = 4
        rc = <optimized out>
        parent_pid = 0
        child_pid = 13310
        call_id = <optimized out>
        peer_call_id = <optimized out>
        buf = "\000t\021\202\277\377\377\377\377\071\032\224\000\020\021\202\277<\203\004\b\370\020\202\277d\225\000\370\230\225\000\001\000\000\000\000\000\000\000\333b\224\000\260\232\225\000b\000\000\000\030\000\000\000\362;\005\b\a\000\000\000\326\331\310\000\002\217\324\000Qk\320\000l\000\000\000\000\000\000\000\034\207\004\b\360e\005\b", '\000' <repeats 12 times>"\230, u\272\000\000p\237\252\364o\324\000\030\000\000\000\362;\005\b\a\000"
        pppdargc = 0
        pppdargv = 0xbf8211f0
        phonenrbuf = "\000\356\341\310\000\a\000\000\000\220?\000\a\000\000\000\240\341\310\000\\e\005\b\000\000\000\000\245\330\310\000\260\235\004\b\000\000\000\000\001\000\000\000\030\000\000\000!\216\004\b\364o\324\000\320Q\324\000\\e\005\b"
        phonenr = 0x0
        launchpppd = 0
        debug = 0
        __FUNCTION__ = "main"
(gdb)

Just for your information: I had the segfault again today, same backtrace.

I've posted the backtrace upstream; we'll see if anyone can figure out what's going on.

The upstream developer wonders if you could run pptp via valgrind, or run memtest on the affected system?

http://sourceforge.net/mailarchive/forum.php?thread_name=20111101113139.GA16011%40us.netrek.org&forum_name=pptpclient-devel

I don't know how to use valgrind, sorry.

memtest on the affected system is ok, at least it was short time ago before installing F16 Beta, before installing a new release of Fedora I always do a memtest to be shure my memory is ok.

I know very well the effect of currupted memory, and I don't want to report 	phantom bugs.

Also no other process on this system is crashing with a segfault randomly. On a system with corrupted memory this is unusual.

And the bug locks very repeatable for me, today I had it again, and it was the same source line again with very simular data dumped by backtrace.

If you want I can make a backtrace again with the next core dump to proof this.

I made the following now:

I checked out the acutal CVS of pptp an build it myself with debug symbols on.

Now the upstream developer will have the original line numbers if the crash happens again. And he can be shure what revision of his code is running

Only thing I can do now is waiting for the next crash I think.

Short interim report:

Since using the self compiled ppptp form the aktual CVS no more segfault til now.

But I think, we have to wait a little longer, but it seems to be better.

Last week I had the segfault nearly every day, I'll give a new feedback after the weekend.

No segfault with the self build pptp binary from the CVS to this day.

I'll give next report end of the week.

I've taken another look at the differences between the Fedora code and the CVS code and I've found three sets of differences:

1. Porting to Solaris, which is exclusively code bracketed with:

   #if defined (__SVR4) && defined (__sun) /* Solaris */
   ...
   #endif

   So I think that can be discounted.

2. Patch from David Lamparter adding support for setting SO_MARK for the PPTP TCP control connection as well as on the GRE packets:

   http://marc.info/?l=pptpclient-devel&m=129830086208165

3. Patch from David Lamparter implementing the --nohostroute option:

   http://marc.info/?l=pptpclient-devel&m=129917040302942

I don't think any of these changes are related so I'm wondering how you built the CVS code, and which compiler options were used? The Fedora build uses the distribution-standard set of compiler flags:

gcc -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4  -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables ...

If you've used different compiler options, maybe that makes a difference?

I used the default Makefile provided in the CVS:

# make
echo "/* text added by Makefile target config.h */" > config.h
echo "#define PPTP_LINUX_VERSION \"1.7.2\"" >> config.h
echo "#define PPPD_BINARY \"/usr/sbin/pppd\"" >> config.h
echo "#define IP_BINARY \"/bin/ip\"" >> config.h
gcc -Wall -O -Wuninitialized -g    -c -o pptp.o pptp.c
gcc -Wall -O -Wuninitialized -g    -c -o pptp_gre.o pptp_gre.c
gcc -Wall -O -Wuninitialized -g    -c -o ppp_fcs.o ppp_fcs.c
gcc -Wall -O -Wuninitialized -g    -c -o pptp_ctrl.o pptp_ctrl.c
gcc -Wall -O -Wuninitialized -g    -c -o dirutil.o dirutil.c
gcc -Wall -O -Wuninitialized -g    -c -o vector.o vector.c
gcc -Wall -O -Wuninitialized -g    -c -o inststr.o inststr.c
gcc -Wall -O -Wuninitialized -g    -c -o util.o util.c
gcc -Wall -O -Wuninitialized -g    -c -o version.o version.c
gcc -Wall -O -Wuninitialized -g    -c -o test.o test.c
gcc -Wall -O -Wuninitialized -g    -c -o pptp_quirks.o pptp_quirks.c
gcc -Wall -O -Wuninitialized -g    -c -o orckit_quirks.o orckit_quirks.c
gcc -Wall -O -Wuninitialized -g    -c -o pqueue.o pqueue.c
gcc -Wall -O -Wuninitialized -g    -c -o pptp_callmgr.o pptp_callmgr.c
gcc -Wall -O -Wuninitialized -g    -c -o routing.o routing.c
gcc -Wall -O -Wuninitialized -g    -c -o pptp_compat.o pptp_compat.c
gcc -o pptp pptp.o pptp_gre.o ppp_fcs.o pptp_ctrl.o dirutil.o vector.o inststr.o util.o version.o test.o pptp_quirks.o orckit_quirks.o pqueue.o pptp_callmgr.o routing.o pptp_compat.o  -lutil
pod2man pptpsetup > pptpsetup.8

Building like that should result in a pptp that can't change the routing table as Fedora's "ip" binary is in /sbin rather than /bin. You'd do "make IP=/sbin/ip" to fix that.

I can think of a couple of experiments we could do at this point:

1. You could build the CVS code using Fedora's compiler flags:

  make CFLAGS="-Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4  -m32 -march=i686 -mtune=atom
-fasynchronous-unwind-tables" IP=/sbin/ip

2. I could build an RPM using the Fedora code and upstream's compiler flags for you to try.

Would you be willing to try either or both of these?

I did 1.:

# make CFLAGS="-Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4  -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables" IP=/sbin/ip
gcc -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4  -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables   -c -o pptp.o pptp.c
gcc -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4  -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables   -c -o pptp_gre.o pptp_gre.c
gcc -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4  -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables   -c -o ppp_fcs.o ppp_fcs.c
gcc -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4  -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables   -c -o pptp_ctrl.o pptp_ctrl.c
gcc -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4  -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables   -c -o dirutil.o dirutil.c
gcc -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4  -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables   -c -o vector.o vector.c
gcc -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4  -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables   -c -o inststr.o inststr.c
gcc -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4  -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables   -c -o util.o util.c
util.c: In Funktion »sigpipe_read«:
util.c:145:7: Warnung: Der Rückgabewert von »read«, der mit dem Attribut warn_unused_result deklariert wurde, wird ignoriert [-Wunused-result]
util.c: In Funktion »sigpipe_handler«:
util.c:121:8: Warnung: Der Rückgabewert von »write«, der mit dem Attribut warn_unused_result deklariert wurde, wird ignoriert [-Wunused-result]
gcc -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4  -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables   -c -o version.o version.c
gcc -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4  -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables   -c -o test.o test.c
gcc -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4  -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables   -c -o pptp_quirks.o pptp_quirks.c
gcc -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4  -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables   -c -o orckit_quirks.o orckit_quirks.c
gcc -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4  -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables   -c -o pqueue.o pqueue.c
gcc -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4  -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables   -c -o pptp_callmgr.o pptp_callmgr.c
pptp_callmgr.c: In Funktion »callmgr_main«:
pptp_callmgr.c:222:17: Warnung: Der Rückgabewert von »read«, der mit dem Attribut warn_unused_result deklariert wurde, wird ignoriert [-Wunused-result]
pptp_callmgr.c:223:17: Warnung: Der Rückgabewert von »read«, der mit dem Attribut warn_unused_result deklariert wurde, wird ignoriert [-Wunused-result]
pptp_callmgr.c: In Funktion »call_callback«:
pptp_callmgr.c:76:18: Warnung: Der Rückgabewert von »write«, der mit dem Attribut warn_unused_result deklariert wurde, wird ignoriert [-Wunused-result]
gcc -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4  -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables   -c -o routing.o routing.c
routing.c: In Funktion »routing_init«:
routing.c:117:8: Warnung: Der Rückgabewert von »fgets«, der mit dem Attribut warn_unused_result deklariert wurde, wird ignoriert [-Wunused-result]
gcc -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4  -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables   -c -o pptp_compat.o pptp_compat.c
gcc -o pptp pptp.o pptp_gre.o ppp_fcs.o pptp_ctrl.o dirutil.o vector.o inststr.o util.o version.o test.o pptp_quirks.o orckit_quirks.o pqueue.o pptp_callmgr.o routing.o pptp_compat.o  -lutil
pod2man pptpsetup > pptpsetup.8

Now waiting if the segfault happens again.

Short question:

Could the segfault relate to the bug corrected here:

http://koji.fedoraproject.org/koji/buildinfo?buildID=270759

My own builds all where created with glibc-2.14.90-14 and I had no crash with all my own builds till now?

Nevertheless I will let the build of my last post run till weekend end the try to switch back to the original pptp binary and look if the segfault will appear again.

Perhaps my provider has changend something and because of this the segfault does not happen. Therfore I'll do the back-to-back test to check this.

(In reply to comment #14)
> Short question:
> 
> Could the segfault relate to the bug corrected here:
> 
> http://koji.fedoraproject.org/koji/buildinfo?buildID=270759

I doubt it. That bug appears to have been introduced in October but the pptp package in F-16 was originally built for F-15 back in February.

> Perhaps my provider has changed something and because of this the segfault
> does not happen. Therefore I'll do the back-to-back test to check this.

OK, thanks.

This night I had the sgefault again with my self build pptp binary from CVS sources and the distribution-standard set of compiler flags from comment 13:

Nov 11 01:08:14 han kernel: [300864.120816] pptpcm[622]: segfault at 4e12470 ip 0804e93e sp bfb5a610 error 4 in pptp[8048000+e000]

Sad to say I have no core dump for backtrace because I booted my server in the meantime an forgot to set the ulimit.

But I think we are on the right track, it ist very likely the same seg fault as before and it happend again with distribution-standard set of compiler flags.

What should I do next to confirm this?

Try this build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3507432

I've changed -O2 to -O0 but otherwise left the compiler flags alone.

Ok, I'll try it and report.

Short interim report:

No segfault with your new build so far, looks good. If non happens til weekend, I think we got it.

No segfault for a week now with the build from http://koji.fedoraproject.org/koji/taskinfo?taskID=3507432.

I think, the -O0 did it.

Optimization may reveal bugs in the source code, which I think is the case here.

Instead of hand-compiling the latest CVS source, I'd suggest either hand-compiling the same sources as in the Fedora package, or trying a Fedora package (compiled with default %optflags) compiled using the newest sources.

(In reply to comment #21)
> Optimization may reveal bugs in the source code, which I think is the case
> here.
> 
> Instead of hand-compiling the latest CVS source, I'd suggest either
> hand-compiling the same sources as in the Fedora package, or trying a Fedora
> package (compiled with default %optflags) compiled using the newest sources.

The build that Michael has been running for the last week has the latest upstream sources (with the exception of the Solaris compatibility patch described in Comment #10) and the Fedora %{optflags} with -O2 changed to -O0.

In Comment #16 Michael reported that the same code (plus the Solaris patch) compiled with standard Fedora %{optflags} eventually segfaulted.

So it's either the Solaris patch or the %{optflags} that made the difference it would seem. And remember that the Solaris patch is the addition of code bracketed by:

   #if defined (__SVR4) && defined (__sun) /* Solaris */
   ...
   #endif

So I'm pretty certain it's the %{optflags} that are precipitating this problem.

OK. But the issue still probably is that the optimization just reveals a bug in the source code that for some reason isn't manifested at lower levels of optimization (I saw a bug exactly like this in cppcheck).

Sorry to say: at the moment the segfault was there again with your build.

Same in the Logfile as in my first post:

Nov 18 17:10:35 han kernel: [187512.120518] pptpcm[20554]: segfault at d99470 ip 080500e1 sp bff6fc78 error 4 in pptp[8048000+f000]
Nov 18 17:10:35 han pptp[20554]: vpn_ppp9 log[pptp_read_some:pptp_ctrl.c:566]: read error: Connection reset by peer
Nov 18 17:10:35 han pptp[20554]: vpn_ppp9 log[callmgr_main:pptp_callmgr.c:263]: Closing connection (shutdown)
Nov 18 17:10:35 han pptp[20554]: vpn_ppp9 log[pptp_send_ctrl_packet:pptp_ctrl.c:637]: write error: Broken pipe
Nov 18 17:10:35 han pptp[20554]: vpn_ppp9 log[call_callback:pptp_callmgr.c:81]: Closing connection (call state)
Nov 18 17:10:35 han pptp[20554]: vpn_ppp9 log[pptp_read_some:pptp_ctrl.c:566]: read error: Bad file descriptor

Without optimization  the error is there also, but not so often. But in the meantime I think the optimization is not the key because I found out a new fact.

After the segfault the connection is established again immediately from ppp-watch and the login is successful.

When I kill the connection "by hand" with the kill -9 command to pptp or by shutting down the underlaying eth device, I cannot login successful immediate.This is what I found out now (my provider blocks the login until the server runs on a echo timeout I think). I have to wait about a minute or so.

So this for me looks like my provider trys to sutdown the connection from server side and this leeds to the segfault.

Maybe it is provider realated and my provider sends crontrol erroneous messages, I dont't know.

Now I had no segfault for a whole week with the build without optimization.

It is undoubtably much better with this build.

No segfault for another week, without optimization it is much more stable.

Still no segfault till now, perhaps to one I had without optimization was something differnt. With your build from http://koji.fedoraproject.org/koji/taskinfo?taskID=3507432 pptp the first time is stable and reliable for me.

I have another build for you to try. This one has the -O2 optimization flags back again but I've added patches that address almost all of the compiler warnings, including the potentially related ones about comparisons of signed and unsigned values, and unsafe typecasts violating strict anti-aliasing rules:

http://koji.fedoraproject.org/koji/taskinfo?taskID=3579744

Ok, thx, I installed it.

I'll try out and report.

Till now no segfault with your new build, I'll give next report next week.

All ok till now, no segfault, still looks very good.

Still no segfault with your latest build, looks very good

No sgefault til today, still looks good.

pptp-1.7.2-14.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/pptp-1.7.2-14.fc16

pptp-1.7.2-14.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/pptp-1.7.2-14.fc15

As it's looking so good, I've done an official build now and will push it for F-15 and F-16 in a week or so. There are no code changes from the last test build. Thanks for the testing.

pptp-1.7.2-14.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

pptp-1.7.2-14.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. 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 '16'.

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 16'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 16 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, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

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

Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.