On 1/8/08, Kevin Stam <[EMAIL PROTECTED]> wrote: > Either all of the various systems rtorrent crashes have similar bugs, or > rtorrent has bugs. I don't currently have the time to ascertain which is > which. Logic tells me it's more likely rtorrent, but I'm not a coder. Just > tried to help out, that's all.
Not sure that "buggy" is the right word for what rtorrent is doing ... maybe it's more like "rude". At least on my boxen (even the ones that lock up), rtorrent downloads correctly, it checks hashes and discards bad data. It's just that the specific method used to do this can push certain parts of the host OS very hard. I further suspect that you could write a simple rtorrent "simulator" - create a zillion little maps, read and write them randomly - and get the same behaviour as real rtorrent. I'm very willing to entertain the notion that there are multiple buggy and/or insufficiently robust memory management systems out there. A lot of the code might be called "scary" or "legacy" or "time-tested"... I don't consider it likely that the original designers of UNIX VM (or even the new UVM) foresaw an application beating up on mmap() the way rtorrent does. CK -- GDB has a 'break' feature; why doesn't it have 'fix' too?
