Bug 25361

Summary: dump(8) command segfaults
Product: Base System Reporter: Christian Weisgerber <naddy>
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 5.0-CURRENT   
Hardware: Any   
OS: Any   

Description Christian Weisgerber 2001-02-25 20:40:00 UTC
The dump(8) command segfaults:

$ dump 0af /dev/null /
  DUMP: Date of this level 0 dump: Sun Feb 25 20:44:21 2001
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/da0a (/) to /dev/null
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 67655 tape blocks.
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: SIGSEGV: ABORTING!
  DUMP: SIGSEGV: ABORTING!
  DUMP: SIGSEGV: ABORTING!
  DUMP: SIGSEGV: ABORTING!
  DUMP: SIGSEGV: ABORTING!
Segmentation fault (core dumped)

dump was working fine in -current as of Dec 25.  The only changes
to it since then are the introduction of <sys/queue.h> instead of
a home-rolled list and the replacement of '\007' with '\a'.  These
changes are innocuous; if backed out, dump still segfaults.  This
suggests that the problem has been triggered by a kernel change.

Fix: 

None known.
How-To-Repeat: 
$ dump 0af /dev/null /
Comment 1 mjacob 2001-02-25 20:41:23 UTC
Addenda: this apparently only occurs on alpha.
Comment 2 mjacob 2001-03-05 21:33:56 UTC
Both the -stable and -current with kernels and userland later than February 26
do not show this problem.

A -current with a userland of 2/13 and a kernel from yesterday shows this
problem. 

I believe the problem has been addressed, but I'll reconfirm tonite after a
buildworld.

-matt



> 
> >Number:         25361
> >Category:       bin
> >Synopsis:       dump(8) command segfaults
> >Confidential:   no
> >Severity:       serious
> >Priority:       medium
> >Responsible:    freebsd-bugs
> >State:          open
> >Quarter:        
> >Keywords:       
> >Date-Required:
> >Class:          sw-bug
> >Submitter-Id:   current-users
> >Arrival-Date:   Sun Feb 25 12:40:00 PST 2001
> >Closed-Date:
> >Last-Modified:
> >Originator:     Christian Weisgerber
> >Release:        FreeBSD 5.0-CURRENT alpha
> >Organization:
> >Environment:
> System: FreeBSD kemoauc.mips.inka.de 5.0-CURRENT FreeBSD 5.0-CURRENT #4: Sat Feb 24 14:37:31 CET 2001 naddy@kemoauc.mips.inka.de:/usr/src/sys/compile/KEMOAUC alpha
> 
> >Description:
> 
> The dump(8) command segfaults:
> 
> $ dump 0af /dev/null /
>   DUMP: Date of this level 0 dump: Sun Feb 25 20:44:21 2001
>   DUMP: Date of last level 0 dump: the epoch
>   DUMP: Dumping /dev/da0a (/) to /dev/null
>   DUMP: mapping (Pass I) [regular files]
>   DUMP: mapping (Pass II) [directories]
>   DUMP: estimated 67655 tape blocks.
>   DUMP: dumping (Pass III) [directories]
>   DUMP: dumping (Pass IV) [regular files]
>   DUMP: SIGSEGV: ABORTING!
>   DUMP: SIGSEGV: ABORTING!
>   DUMP: SIGSEGV: ABORTING!
>   DUMP: SIGSEGV: ABORTING!
>   DUMP: SIGSEGV: ABORTING!
> Segmentation fault (core dumped)
> 
> dump was working fine in -current as of Dec 25.  The only changes
> to it since then are the introduction of <sys/queue.h> instead of
> a home-rolled list and the replacement of '\007' with '\a'.  These
> changes are innocuous; if backed out, dump still segfaults.  This
> suggests that the problem has been triggered by a kernel change.
> 
> >How-To-Repeat:
> 
> $ dump 0af /dev/null /
> 
> >Fix:
> 
> None known.
> 
> >Release-Note:
> >Audit-Trail:
> >Unformatted:
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-bugs" in the body of the message
>
Comment 3 Christian Weisgerber 2001-03-06 14:01:22 UTC
Matthew Jacob:
> 
> Both the -stable and -current with kernels and userland later than February 26
> do not show this problem.

Sorry, but I'm running kernel and userland from March 4, and this
is *not* resolved.

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de
Comment 4 mjacob 2001-03-06 15:25:57 UTC
-current or -stable?


On Tue, 6 Mar 2001, Christian Weisgerber wrote:

> Matthew Jacob:
> > 
> > Both the -stable and -current with kernels and userland later than February 26
> > do not show this problem.
> 
> Sorry, but I'm running kernel and userland from March 4, and this
> is *not* resolved.
> 
> -- 
> Christian "naddy" Weisgerber                          naddy@mips.inka.de
>
Comment 5 Christian Weisgerber 2001-03-06 16:42:21 UTC
Matthew Jacob:

> > Sorry, but I'm running kernel and userland from March 4, and this
> > is *not* resolved.
> 
> -current or -stable?

-CURRENT.

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de
Comment 6 Matt Jacob freebsd_committer freebsd_triage 2001-03-28 17:20:53 UTC
State Changed
From-To: open->closed

John Baldwin fixed the kernel problems that caused this.