NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: bin/56643: problem with restore(8)

The following reply was made to PR bin/56643; it has been noted by GNATS.

From: Paul Goyette <>
To: Christos Zoulas <>
Subject: Re: bin/56643: problem with restore(8)
Date: Tue, 25 Jan 2022 12:07:59 -0800 (PST)

 (Logging some IRC debugging to the audit trail)
 I did a cross-compare between old/new versions of dump/restore, with
 the following results
     old_dump | old_restore  ---> works
     old_dump | new_restore ---> works
     new_dump | old_restore ---> works AFAICT but the lost data message
                                 (and check) doesn't exist in old restore
     new_dump | new_restore ---> fails as before
 I even tried to say 'y' to the "abort" question, and 'y' to the
 "dump core" question;  here's the backtrace
    #0  0x0000776a82b9c04a in _lwp_kill () from /lib/
    #1  0x0000776a82b9c59a in abort ()
        at /build/netbsd-local/src_ro/lib/libc/stdlib/abort.c:74
    #2  0x00000000d6c0dcb4 in panic.cold ()
    #3  0x00000000d6c0baa6 in getfile ()
    #4  0x00000000d6c0bd32 in extractfile ()
    #5  0x00000000d6c05775 in createleaves ()
    #6  0x00000000d6c0e1f0 in main ()
 I also re-ran both new_dump tests.  With new_restore, it checks for
 the lost-data condition and result in a "truncated" output file.
 With old_restore, the check/message doesn't exist, so restore just
 continues;  however diff(1) reports that the output file does not
 match the input file.
 It seems pretty sure that dump(8) is broken in some way.
 | Paul Goyette       | PGP Key fingerprint:     | E-mail addresses:    |
 | (Retired)          | FA29 0E3B 35AF E8AE 6651 |    |
 | Software Developer | 0786 F758 55DE 53BA 7731 |  |
 | & Network Engineer |                          | |

Home | Main Index | Thread Index | Old Index