Hi David!
The code after the else is completely unnecessary. You code was this.
Notice, that in the if(err==FAIL) case you return, but you do not put
back the message in the pool. Good that it works for you now.
Best,
Miklos
event void AMSend.sendDone(message_t* msg, error_t err) {
if(err==FAIL) {
printf("sendDone() returned FAIL...\n");
printfflush();
return;
}
if(call PacketAcknowledgements.wasAcked(msg)==FALSE) {
if(msg==&testMessage) { // This is an unbuffered packet
printf("Unbuffered packet was not
acknowledged...\n");
printfflush();
}
else { // This is a packet from the queue
printf("Buffered packet was not
acknowledged...\n");
printfflush();
call testPool.put(msg);
}
}
else {
if(msg==&testMessage) { // This is an unbuffered packet
printf("Unbuffered packet was
acknowledged...\n");
printfflush();
}
else { // This is a packet from the queue
printf("Buffered packet was acknowledged...\n");
printfflush();
call testPool.put(msg);
}
}
}
On Thu, Jun 23, 2011 at 8:10 PM, David Piotrowski <[email protected]> wrote:
> 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 <[email protected]>
>> 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 <[email protected]>
>>>> 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
>>>>> [email protected]
>>>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>>>>>
>>>
>>>
>
>
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
