Description of problem: KDE Crashes. Fedora Core 3. PPTP installed exactly as listed at http://pptpclient.sourceforge.net/howto-fedora-core-3.phtml. If the pptp-client application is closed while it is trying to connect to a pptp server, the whole kde session ends abruptly and the fedora login screen appears. It appears that pptp does something to cause KDE windows manager to crash. Version-Release number of selected component (if applicable): Versions for pptp are listed at http://pptpclient.sourceforge.net/howto-fedora-core-3.phtml. How reproducible: Every time. Steps to Reproduce: 1. Start to connect to a PPTP server, and click the "Stop" button before the connection is made. 2. Or you can try to connect to a non-existent PPTP server IP and click stop. This is probably the easiest way. 3. Actual results: Abrupt end to kde session and return to login screen. Expected results: KDE not crashing. Additional info: I've posted this bug with the kde folks and also attached a couple of /var/log/messages file. The best I can see from the messages file is that gdm (whatever that is) is the last thing done right before the session closes.
This has been posted at www.kde.org as Bug 97547. Here's the information from the kde bug: ------- Additional Comment #1 From Stephan Binner 2005-01-23 14:06 ------- Any hint about the reason in ~/.xsession-errors? ------- Additional Comment #2 From Kasey Erickson 2005-01-23 22:16 ------- That file doesn't appear to exist when doing "ls -la ~". ------- Additional Comment #3 From Lubos Lunak 2005-01-25 12:49 ------- There should be some log file where all errors from applications running in X session go, it's usually ~/.xsession-errors, but if Fedora has different name for it, then I suggest you ask on some Fedora help forum or similar. And since the whole session terminates, it's very unlikely it's actually kwin problem. It might be ksmserver problem, but I personally guess it's X crashing, so please attach also your X log file (/var/log/XFree86.0.log usually). ------- Additional Comment #4 From Kasey Erickson 2005-01-25 16:36 ------- Created an attachment (id=9290) Xorg log ------- Additional Comment #5 From Kasey Erickson 2005-01-25 16:37 ------- Created an attachment (id=9291) Another Xorg log ------- Additional Comment #6 From Kasey Erickson 2005-01-25 16:39 ------- There was not /var/log/XFree86.0.log just /var/log/Xorg.0.log and /var/log/Xorg.0.log.old. Please find both attached. Please give these a look. If it appears to be an integration issue I'll work with the fedora project to resolve it. ------- Additional Comment #7 From Lubos Lunak 2005-01-25 16:57 ------- And these are the log files from right after your X/KDE/whatever crashed because of the problem? ------- Additional Comment #8 From Kasey Erickson 2005-01-26 08:15 ------- Not right after. I just produced the crash and did a diff on the /var/log/Xorg.0.log file and the same file before the crash. Here are the results: [root@localhost log]# more Xorg.0.log.CrashDiff 733a734,739 > (WW) Open APM failed (/dev/apm_bios) (No such file or directory) > (==) NV(0): Write-combining range (0xd0000000,0x8000000) > (**) NV(0): DPMS enabled > (==) RandR enabled > (II) Mouse0: ps2EnableDataReporting: succeeded > SetClientVersion: 0 8 It doesn't seem to reveal much. I also combed through /var/log/messages to see if there was a sore thumb there. Please see the next attached file. The line "Jan 26 00:05:10 localhost gdm(pam_unix)[3154]: session closed for user kerickson" I think is where KDE exists and the login screen appears. ------- Additional Comment #9 From Kasey Erickson 2005-01-26 08:18 ------- Created an attachment (id=9295) /var/log/messages.pptpCrash Start of pptp session to when it exits (causing the crash in question), and KDE starting up again when I login. /var/log/messages.pptpCrash: Jan 26 00:05:06 localhost pppd[15275]: pppd 2.4.2 started by root, uid 0 Jan 26 00:05:06 localhost pppd[15275]: Using interface ppp0 Jan 26 00:05:06 localhost pppd[15275]: Connect: ppp0 <--> /dev/pts/3 Jan 26 00:05:07 localhost pptp[15276]: anon log[main:pptp.c:243]: The synchronous pptp option is NOT activated Jan 26 00:05:07 localhost pptp[15289]: anon log[ctrlp_rep:pptp_ctrl.c:243]: Sent control packet type is 1 'Start-Control-Connection-Request' Jan 26 00:05:07 localhost pptp[15289]: anon log[ctrlp_disp:pptp_ctrl.c:721]: Received Start Control Connection Reply Jan 26 00:05:07 localhost pptp[15289]: anon log[ctrlp_disp:pptp_ctrl.c:755]: Client connection established. Jan 26 00:05:08 localhost pptp[15289]: anon log[ctrlp_rep:pptp_ctrl.c:243]: Sent control packet type is 7 'Outgoing-Call-Request' Jan 26 00:05:08 localhost pptp[15289]: anon log[ctrlp_disp:pptp_ctrl.c:841]: Received Outgoing Call Reply. Jan 26 00:05:08 localhost pptp[15289]: anon log[ctrlp_disp:pptp_ctrl.c:880]: Outgoing call established (call ID 0, peer's call ID 1). Jan 26 00:05:09 localhost pppd[15275]: Terminating on signal 2. Jan 26 00:05:09 localhost pptp[15289]: anon log[callmgr_main:pptp_callmgr.c:249]: Closing connection Jan 26 00:05:09 localhost pptp[15289]: anon log[ctrlp_rep:pptp_ctrl.c:243]: Sent control packet type is 12 'Call-Clear-Request' Jan 26 00:05:09 localhost su[15236]: Warning! Could not relabel with user_u:object_r:devpts_t, not relabeling. Jan 26 00:05:09 localhost su(pam_unix)[15236]: session closed for user root Jan 26 00:05:09 localhost pppd[15275]: Modem hangup Jan 26 00:05:09 localhost pppd[15275]: Connection terminated. Jan 26 00:05:09 localhost pppd[15275]: Exit. Jan 26 00:05:09 localhost pptp[15289]: anon log[ctrlp_disp:pptp_ctrl.c:912]: Call disconnect notification received (call id 43328) Jan 26 00:05:10 localhost gdm(pam_unix)[3154]: session closed for user kerickson Jan 26 00:05:10 localhost dbus: avc: 1 AV entries and 1/512 buckets used, longest chain length 1 Jan 26 00:05:11 localhost pptp[15289]: anon log[ctrlp_rep:pptp_ctrl.c:243]: Sent control packet type is 12 'Call-Clear-Request' Jan 26 00:05:11 localhost pptp[15289]: anon log[pptp_conn_close:pptp_ctrl.c:425]: Closing PPTP connection Jan 26 00:05:11 localhost pptp[15289]: anon log[ctrlp_rep:pptp_ctrl.c:243]: Sent control packet type is 3 'Stop-Control-Connection-Request' Jan 26 00:05:15 localhost pptp[15289]: anon log[call_callback:pptp_callmgr.c:77]: Closing connection Jan 26 00:05:20 localhost gdm(pam_unix)[3154]: session opened for user kerickson by (uid=0) Jan 26 00:05:32 localhost su(pam_unix)[15491]: session opened for user root by kerickson(uid=500) Jan 26 00:10:01 localhost crond(pam_unix)[15589]: session opened for user root by (uid=0) Jan 26 00:10:01 localhost crond(pam_unix)[15592]: session opened for user root by (uid=0) Jan 26 00:10:02 localhost crond(pam_unix)[15589]: session closed for user root Jan 26 00:10:02 localhost crond(pam_unix)[15592]: session closed for user root
Maybe this comment has nothing to do with this bug, but it may be additionally informative. Since I installed kernel 2.6.15-1.1831_FC4, my network tends to get corrupted if I receive a media stream from the internet. I use the latest version of pptp (1.7.1 from extra's). For unknown reasons, the network (eth0 to internet, eth1 internally, and ppp0 for the adsl connection) simply "stops". No DNS anymore, no connection. Restarting pptp and network (through "service network restart" etc) always helps. Never had that with previous FC4 kernels (used that from the start), now I can wait for it once in every half hour with streaming media.
Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you!
The information we've requested above is required in order to review this problem report further and diagnose/fix the issue if it is still present. Since there haven't been any updates to the report in quite a long time now after we've requested additional information, we're assuming the problem is either no longer present in our current OS release, or that there is no longer any interest in tracking the problem. Setting status to CANTFIX, however if you still experience this problem after updating to our latest Fedora Core release and are still interested in Red Hat tracking the issue, and assisting in troubleshooting the problem, please feel free to provide the information requested above, and reopen the report. Thank you in advance. (this message is mass message)