FWIW, I can reproduce it: lshd: write_buffer: do_write length = 256 lshd: write_buffer: do_write closure->length = 293 lshd: garbage collecting... lshd: gc_mark: Memory corrupted! Aborted
I think it has nothing to do with the actual bits sent, but rather that some earlier random data caused the code to take a rarely tested execution path, which has garbage collect bugs in it, which is discovered a while later. In general, as an alternative, perhaps a fork() solution will be less vulnerable to these problems. Btw, is there a way to make the GC more aggressive? E.g., run it after every NEW or KILL? I could use this to track down a GC bug in my patched lsh version. Bennett Todd <[EMAIL PROTECTED]> writes: > on Red Hat 8, I can reliably crash lshd, shutting down all active > sessions and leaving a pid file around so lshd refuses to restart, > by running > > dd if=/dev/random bs=1024 count=1|nc localhost >/dev/null > > a few times. Sadly, capturing the random sequence that blows down an > lshd and replaying it against another one doesn't seem to kill it; > different running instances require different replays of the same > random to kill them. > > Oh well, back to bloody openssh with all its bugs and patches. Drat! > > -Bennett _______________________________________________ lsh-bugs mailing list [EMAIL PROTECTED] http://lists.lysator.liu.se/mailman/listinfo/lsh-bugs
