Hi Miklos,
you were right. I did not put the messages back into the pool in the case of
failure. I corrected this in my example application and now I am no longer able
to reproduce the error I had before. I wonder though why this is the case since
as I said before I never had a run in which a send() or sendDone() gave me an
error, so all packets from the pool should have been returned to the pool after
sending. Does this mean that I have to write code like this to make sure my
application works properly?:
function {
if(whatever) {
do something with the message_t from pool;
return message_t to pool;
return from function;
}
else {
do something else with the message_t from pool;
return message_t to pool;
return from function;
}
return message_t to pool;
return from function;
}
In my eyes the code after the if-else statement is unnecessary since I will
never get there. But in my example application the code that was never reached
in a test run (even though it was reachable in contrast to the example above)
nevertheless changed my programs behavior. In my real program I do still get
the described error and I do not know where to search for leaking packets or
other errors anymore.
Thanks for your advice
David
Am 20.06.2011 um 15:27 schrieb Miklos Maroti:
> Hi David,
>
> On Mon, Jun 20, 2011 at 12:39 PM, David Piotrowski <tin...@zeroflag.eu> wrote:
>> Hi Miklos,
>>
>> I do not get failures, send returns just fine. I am also releasing the
>> packets back to the pool after sondDone occurs.
>
> No, you do NOT put back the message after a sendDone(FAIL) even or a
> send command which fails.
>
>> The packets from the pool are only manipulated after I get them from the
>> pool and before I release them to the pool again, so I think even if they
>> get corrupted in the pool they should be properly setup again before sending
>> them. I am not using Packet.clear though. I'll try that and see whether it
>> has any influence on my results.
>
> You should call Packet.clear(). I suppose, that the MessagePool
> maintains a linked list of entries and stores pointers and that
> corrupts the internal layout, so you have to call Packet.clear() for
> each message.
>
> Best,
> Miklos
>
>>
>> Thanks for your input.
>> David
>>
>> Am 19.06.2011 um 23:45 schrieb Miklos Maroti:
>>
>>> Hi David,
>>>
>>> Do you see any failures? (send fails or sendDone fails?) If any of
>>> those occur, then you have to put the message back to the pool.
>>>
>>> Another thing you should do: call Packet.clear before you set up the
>>> data in the message. The values in the pool can be corrupted. I think
>>> this is the source of your problems.
>>>
>>> Best,
>>> Miklos
>>>
>>> On Sun, Jun 19, 2011 at 11:33 PM, David Piotrowski <tin...@zeroflag.eu>
>>> wrote:
>>>> Hello again,
>>>>
>>>> I did some more investigations on the ACK error I described in my previous
>>>> mail. It seems like I had quite the same error about a year ago but since
>>>> then I used tossim quite a lot and the error did not show up there.
>>>>
>>>> I have written a small example application that shows the error I have.
>>>> The application has a fixed message_t variable and a pool from which it
>>>> gets another message_t. It then sends the fixed message_t and the
>>>> message_t from the pool alternately over and over again. Upon reception
>>>> the receiving node lights the received message on its LED. The nodes print
>>>> some debugging information out on the screen showing which kind of
>>>> message_t they are actually sending and if it is acknowledged.
>>>>
>>>> Depending on the size of the pool used I get different behavior when it
>>>> comes to acknowledgements. For me the configuration of the program
>>>> appended yields no ack for packets that come from the pool but the packets
>>>> not coming from the pool all get acknowledgements. Other pool sizes yield
>>>> other results. In several (maybe all?) configurations the first two
>>>> packets never get acknowledged independent of whether they come from the
>>>> pool or not. Another thing to notice is that although the packets are not
>>>> acknowledged, they have been properly received, which is signaled by the
>>>> blinking LEDs. In some configurations the behaviour of ACKs changes
>>>> between resets of the node.
>>>>
>>>> I am really searching for some advice on this. The actual program I am
>>>> working on is using at least two pools, which I suspect are the reason why
>>>> I never get an ack there although all the messages sent are received and
>>>> everything is working flawless in tossim.
>>>>
>>>> Thanks, David.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Tinyos-help mailing list
>>>> Tinyos-help@millennium.berkeley.edu
>>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>>>>
>>
>>
_______________________________________________
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
