From owner-freebsd-hackers Sun Dec 8 20:32:53 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA24928 for hackers-outgoing; Sun, 8 Dec 1996 20:32:53 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA24909 for ; Sun, 8 Dec 1996 20:32:51 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id VAA11231; Sun, 8 Dec 1996 21:32:47 -0700 (MST) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id VAA10071; Sun, 8 Dec 1996 21:32:16 -0700 (MST) Date: Sun, 8 Dec 1996 21:32:15 -0700 (MST) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: Jake Hamby cc: hackers@freebsd.org Subject: Re: How do I diagnose user-mode PPP coredumps? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk While I can't comment on the problem, one possible reason why it doesn't core dump is that it is running setuid. ppp installs its own signal handler for various signals, including SEGV. What it does is clean things up, then (in the case of sig 11) call abort(3). abort would dump core, except for the fact that the program is setuid. You should (or might; you can on 2.1.5, there have been some changes made in that are in -current, but I don't _think_ this should be one) be able to get around this by running ppp as root. As to the reason why it doesn't exit by itself, it is probably getting hung up somewhere in the signal handler trying to close the line and terminate the connection; if you wait long enough, it may sort itself out. On Sun, 8 Dec 1996, Jake Hamby wrote: > I use the user-mode PPP daemon extensively on my FreeBSD-current box, and > often, after a number of HDLC errors, it will coredump. The ppp.log looks > like: > > 12-08 13:30:21 [143] HDLC errors -> FCS: 5 ADDR: 0 COMD: 0 PROTO: 0 > 12-08 13:31:21 [143] HDLC errors -> FCS: 1 ADDR: 0 COMD: 0 PROTO: 0 > 12-08 13:32:21 [143] HDLC errors -> FCS: 4 ADDR: 0 COMD: 0 PROTO: 0 > 12-08 13:33:21 [143] HDLC errors -> FCS: 1 ADDR: 0 COMD: 0 PROTO: 0 > 12-08 13:35:21 [143] HDLC errors -> FCS: 1 ADDR: 0 COMD: 0 PROTO: 0 > 12-08 13:36:21 [143] HDLC errors -> FCS: 1 ADDR: 0 COMD: 0 PROTO: 0 > 12-08 13:36:21 [143] Signal 11, core dump. > > The weird thing is that process 143 is still alive, and I must manually > "kill -9" it, in order for the phone line to hang up. The other problem > is that I don't get a core file anywhere, because it seems to be trapping > the SIGSEGV. Does anyone else have this problem? What steps should I > follow to start tracing it? I don't know why I'm getting the HDLC errors > in the first place, but I have seen CRC errors using PPP with other OS's, > so it's possible there's a dirty connection on my ISP's end, or on mine. > Any help will be greatly appreciated, and I will post a send-pr when I've > found the culprit. > > -- Jake >