Re: so, can we do something about lesspipe? (+ a cpio bug to back up the argument)

[Lionel Debroux <lionel_debroux () yahoo fr>]

I hope that no distro is configured to let lesspipe call programs which
parse Berkeley DBs, because that's not robust either:

1) I've just experienced corruption of the database used by the "moc"
ncurses-based console audio player, certainly after I used the power
button on my computer without being able to sync first.
Now, as long as that corrupt database is in ~/.moc/cache/tags.db, even
with any corresponding DB log file, moc hangs on startup, pegging one
core at 100% for minutes (that is, until I run `killall -9 mocp`).
Attaching to the process through GDB and peeking through backtraces
every few seconds always shows something below __bam_search -> __db_lget
-> __lock_vec.

However:
* db5.3_verify prints several error messages and exits with a status
code of 1, as it should;
* db5.3_dump -d a is happy as well with that file, exiting with a status
code of 0.
The only thing wrong with that database seems to be a fully zero-ed page.

2) that gave me the idea to fuzz db5.3_verify on Debian sid amd64, using
a trivial test database:
$ rm -f test.db
$ echo -e "test\ntest" | db5.3_load -T -t hash test.db
$ zzuf -qcs0:200 -U 10 -C 10 db5.3_verify test.db
zzuf[s=1,r=0.004]: signal 9 (memory exceeded?)
zzuf[s=12,r=0.004]: signal 9 (memory exceeded?)
zzuf[s=64,r=0.004]: signal 9 (memory exceeded?)
zzuf[s=66,r=0.004]: signal 9 (memory exceeded?)
zzuf[s=110,r=0.004]: signal 8 (SIGFPE)
zzuf[s=188,r=0.004]: signal 9 (memory exceeded?)
$ zzuf -qcs0:2000 -C 10 db5.3_dump -d a test.db
zzuf[s=110,r=0.004]: signal 8 (SIGFPE)
zzuf[s=290,r=0.004]: signal 8 (SIGFPE)
zzuf[s=445,r=0.004]: signal 8 (SIGFPE)
zzuf[s=893,r=0.004]: signal 8 (SIGFPE)
zzuf[s=1407,r=0.004]: signal 8 (SIGFPE)
zzuf[s=1540,r=0.004]: signal 8 (SIGFPE)
zzuf[s=1695,r=0.004]: signal 8 (SIGFPE)
zzuf[s=1736,r=0.004]: signal 8 (SIGFPE)


Lionel.