From kjwolf@seismic.de Tue Oct  5 10:36:53 1999
Return-Path: <kjwolf@seismic.de>
Received: from mout00.kundenserver.de (mout00.kundenserver.de [195.20.224.69])
	by hub.freebsd.org (Postfix) with ESMTP id 3A12314E32
	for <FreeBSD-gnats-submit@freebsd.org>; Tue,  5 Oct 1999 10:36:38 -0700 (PDT)
	(envelope-from kjwolf@seismic.de)
Received: from [195.20.224.75] (helo=mrelay00.kundenserver.de)
	by mout00.kundenserver.de with esmtp (Exim 2.12 #2)
	id 11YYVy-0008Gn-00
	for FreeBSD-gnats-submit@freebsd.org; Tue, 5 Oct 1999 19:36:38 +0200
Received: from [62.157.66.55] (helo=solling.seismic.de)
	by mrelay00.kundenserver.de with esmtp (Exim 2.12 #2)
	id 11YYVw-0002iN-00
	for FreeBSD-gnats-submit@freebsd.org; Tue, 5 Oct 1999 19:36:37 +0200
Received: (from kjwolf@localhost)
	by solling.seismic.de (8.9.3/8.9.3) id TAA18479;
	Tue, 5 Oct 1999 19:37:02 +0200 (CEST)
	(envelope-from kjwolf)
Message-Id: <199910051737.TAA18479@solling.seismic.de>
Date: Tue, 5 Oct 1999 19:37:02 +0200 (CEST)
From: Klaus-Juergen Wolf <kjwolf@seismic.de>
To: FreeBSD-gnats-submit@freebsd.org
Subject: PPP userland/client (3.3-REL) throws core
X-Send-Pr-Version: 3.2

>Number:         14145
>Category:       bin
>Synopsis:       PPP userland/client throws core
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Oct  5 10:40:00 PDT 1999
>Closed-Date:    Sat Oct 16 03:11:10 PDT 1999
>Last-Modified:  Sat Oct 16 03:11:31 PDT 1999
>Originator:     Klaus-Juergen Wolf
>Release:        FreeBSD 3.3-RELEASE i386
>Organization:
>Environment:

i386 (Pentium II-300, 96MB RAM), ELSA TanGo 2000 (ISDN-"Modem") at
serial COM interface (and, it appears, similar ELSA products)

>Description:

Under certain circumstances (it appears, high I/O load), PPP
userland/client unpredictably throws a core. That didn't happen
with 3.2-RELEASE and, as I remember, neither with 3.3-RC. (I have
updated the "Modem"'s firmware in the meantime, but that doesn't
appear to be the real reason, since it works under 3.2-REL like
it did before.)

>How-To-Repeat:

Under certain circumstances (empty cache, empty proxy), browsing
http://www.jpc.de/ has seemed to be a reliable method to produce a
PPP's core dump, while there were several I/O-intensive processes in
the background (load above 1.8). It's a site with very many objects are
to be loaded at the same time.

>Fix:
	
Unknown. Brian has been informed, but I lack of the ability to supply
the data he wants.


>Release-Note:
>Audit-Trail:

From: Ruslan Ermilov <ru@ucb.crimea.ua>
To: Klaus-Juergen Wolf <kjwolf@seismic.de>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG,
	Brian Somers <brian@FreeBSD.ORG>
Subject: Re: bin/14145: PPP userland/client (3.3-REL) throws core
Date: Tue, 5 Oct 1999 22:19:45 +0300

 On Tue, Oct 05, 1999 at 07:37:02PM +0200, Klaus-Juergen Wolf wrote:
 > 
 [...]
 > Under certain circumstances (it appears, high I/O load), PPP
 > userland/client unpredictably throws a core. That didn't happen
 > with 3.2-RELEASE and, as I remember, neither with 3.3-RC. (I have
 > updated the "Modem"'s firmware in the meantime, but that doesn't
 > appear to be the real reason, since it works under 3.2-REL like
 > it did before.)
 > 
 [...]
 > 	
 > Unknown. Brian has been informed, but I lack of the ability to supply
 > the data he wants.
 > 
 Yeah, this happened to me too:
 
 Oct  5 10:28:08 relay /kernel: pid 23005 (ppp), uid 0: exited on signal 10 (core dumped)
 Oct  5 20:07:28 relay /kernel: pid 77580 (ppp), uid 0: exited on signal 10 (core dumped)
 
 I have compiled `ppp' with debug symbols, and will send a backtrace on the
 next core.
 
 Anything else, Brian?
 
 -- 
 Ruslan Ermilov		Sysadmin and DBA of the
 ru@ucb.crimea.ua	United Commercial Bank,
 ru@FreeBSD.org		FreeBSD committer,
 +380.652.247.647	Simferopol, Ukraine
 
 http://www.FreeBSD.org	The Power To Serve
 http://www.oracle.com	Enabling The Information Age
 

From: Brian Somers <brian@Awfulhak.org>
To: Ruslan Ermilov <ru@ucb.crimea.ua>
Cc: Klaus-Juergen Wolf <kjwolf@seismic.de>,
	FreeBSD-gnats-submit@freebsd.org, Brian Somers <brian@freebsd.org>
Subject: Re: bin/14145: PPP userland/client (3.3-REL) throws core 
Date: Wed, 06 Oct 1999 05:07:56 +0100

 [.....]
 > Yeah, this happened to me too:
 > 
 > Oct  5 10:28:08 relay /kernel: pid 23005 (ppp), uid 0: exited on signal 10 (core dumped)
 > Oct  5 20:07:28 relay /kernel: pid 77580 (ppp), uid 0: exited on signal 10 (core dumped)
 > 
 > I have compiled `ppp' with debug symbols, and will send a backtrace on the
 > next core.
 > 
 > Anything else, Brian?
 
 Some patches ?  ;^1
 
 Seriously, I believe there's a bug in the way VJ packets are handled 
 where ppp ends up scribbling over the return address on the stack.  
 Once the deed has happened, there's very little information left....
 
 What I think I really need is a way of actually reproducing the 
 problem.  It's never happened to me, but it's been happening to 
 people for years.
 
 I think the only way to catch something like this is to get the 
 compiler to put the function return address in read-only memory so 
 that a stack-scribble will produce a core when it happens rather than 
 after the fact....  Do you know if gcc is capable of doing this ?  Do 
 you know of any better ways of tackling the problem ?
 
 > -- 
 > Ruslan Ermilov		Sysadmin and DBA of the
 > ru@ucb.crimea.ua	United Commercial Bank,
 > ru@FreeBSD.org		FreeBSD committer,
 > +380.652.247.647	Simferopol, Ukraine
 > 
 > http://www.FreeBSD.org	The Power To Serve
 > http://www.oracle.com	Enabling The Information Age
 
 Cheers.
 
 -- 
 Brian <brian@Awfulhak.org>                        <brian@FreeBSD.org>
       <http://www.Awfulhak.org>                   <brian@OpenBSD.org>
 Don't _EVER_ lose your sense of humour !          <brian@FreeBSD.org.uk>
 
 
 
State-Changed-From-To: open->closed 
State-Changed-By: brian 
State-Changed-When: Thu Oct 7 00:32:27 PDT 1999 
State-Changed-Why:  
Fixed in -current.  I'll MFC as soon as Klaus-Juergen confirms it's working ok. 
State-Changed-From-To: closed->open 
State-Changed-By: brian 
State-Changed-When: Thu Oct 7 00:34:12 PDT 1999 
State-Changed-Why:  
Doh!  Wrong PR !  I was thinking ``that isn't ru@'s name'' ! 
State-Changed-From-To: open->closed 
State-Changed-By: brian 
State-Changed-When: Sat Oct 16 03:11:10 PDT 1999 
State-Changed-Why:  
Fixed in -current with *lots* of help from ru. 
Will MFC soon. 
>Unformatted:
