peer_unwant: Assertion `p->nwant > 0' failed
Alex Buie
get an error like this in the log, and btpd dies. Any ideas why this
would occur? If there's anything I can do to help debug, let me know.
It seems to just be a random occurrence.
btpd: btpd/peer.c:291: peer_unwant: Assertion `p->nwant > 0' failed
--
Alex Buie
Network Coordinator / Server Engineer
KWD Services, Inc
Media and Hosting Solutions
+1(703)445-3391
+1(480)253-9640
+1(703)919-8090
ab...@kwdservices.com
On Tue, Feb 8, 2011 at 10:35 PM, Brian Waters <brianm...@gmail.com> wrote:
> Thanks for the input, Nemo. I guess the question, then, is if I came
> up with a good patch to change this behavior (only to accept
> out-of-order keys, and nothing else), would you guys accept it?
>
> Basically, when I found this out, I thought it would be a fun little
> thing to fix, but I don't want to waste my time if it won't be
> accepted anyway.
>
> Thanks,
> Brian Waters
>
>
> On Tue, Feb 8, 2011 at 9:57 PM, Nemosoft Unv. <nemo...@smcc.demon.nl> wrote:
>> Hello,
>>
>> On Thursday 27 January 2011 00:26:02 Brian Waters wrote:
>>> Hi! This is not a full bug report, because I'm not sure if this is
>>> something you guys even consider a bug.
>>>
>>> I have an improperly-formatted .torrent file; specifically, the
>>> "announce" key comes last in the top-level dictionary -- if it were
>>> properly formatted, it would come first. (In a bencoded dictionary,
>>> the keys are supposed to be in alphabetical order.) When I try to add
>>> this torrent using bcli, I get an error:
>>>
>>> error loading '[path]' (Invalid argument).
>>>
>>> Clearly, the problem here is the badly-formatted .torrent file, but
>>> other clients handle it fine, and the .torrent file does contain all
>>> of the information that the daemon needs.
>>
>> Indeed, btpd assumes the bencoded file to be in albetical order. In benc.c it
>> searches through the list of variables and stops if the target variable name
>> is smaller than the current one (see lines 236 and 237).
>>
>> I suppose it shaves off a few microseconds of scanning through the list, but I
>> doubt it really makes that much of an impact.
>>
>>> If it were me, I would have
>>> btpd accept this kind of bad input, but different projects have
>>> different policies.
>>
>> That depends on two things. You wrote "keys are supposed to be in alpabetical
>> order", and various documents on the web agree with you. So basically it's a
>> wrong torrent file, but how strict do you (we) want to be? So far I've never
>> encountered such a torrent file, so yours seem to be the exception.
>>
>> On the other hand, I fail to see the added value of storing bencoded keys
>> alphabetically; if you want to optimize searching throught the list there are
>> many ways to optimize this in memory (I'm assuming any torrent tool will parse
>> the file and stores it in some internal structure; sorting or adding a hash is
>> then a trivial task).
>>
>> So is it a bug in btpd? No. Is it something we can accomodate easily? Yes. Do
>> we want to? I'm inclined to say no... In stead, my suggestion would be to
>> write a small tool or script to fix thoses broken torrents. Or prod the maker
>> of the torrent and tell him/her to use better tools.
>>
>> - Nemo
>>
>>
>>
>>
>