[Click] strange bug

[Amita Ekbote]

Hey,

The bug is kinda solved. I should have posted it , but here are the
details:

I was modifying the packet in the run_timer function of timed source, the
code was something like this
{
output.push(p)
p->data_modify //add sequence number

}

i got the error because the push occurred before the modification, looks
like the packet was accessible for some time and then got deleted. I am not
completely familiar with how the push function works and am not sure when
the packet gets deleted. Looked like a race condition.

Thanks !

On Tue, Feb 16, 2010 at 5:54 PM, Eddie Kohler <kohler at cs.ucla.edu> wrote:

> Hi Amrita,
>
> Sorry, it's been a while.  That is quite a weird tailroom() number!  It
> looks very much like memory corruption.  I have some questions.
>
> - Are you running on a 32- or 64-bit architecture?
> - Would you feel comfortable sharing the code of your modified timedsource?
>
> E
>
>
>
> Amita Ekbote wrote:
>
>> Hello,
>>
>> I am trying to add sequence numbers in the data portion of a packet, so i
>> edited the timedsource.cc to just push the sequence number in the packet.
>> The code converts the number to string, "pushes" the strings length on the
>> packet and copies it. I am getting the following error
>>
>> click: ../lib/packet.cc:416: WritablePacket*
>> Packet::expensive_uniqueify(int32_t, int32_t, bool): Assertion
>> `(extra_headroom >= (int32_t)(-headroom())) && (extra_tailroom >=
>> (int32_t)(-tailroom()))' failed.
>>
>> Initially the packet has no headroom or tailroom. The headroom() and
>> tailroom() return 0. The sequence of function calls is
>> push->expensive_push->expensive_uniqueify. Right before
>> expensive_uniqueify
>> is called the headroom and tailroom are still 0. I printed values before
>> the
>> assertion and I get these:
>>
>> extra headroom 128 headroom 0 extra_tailroom 0 tailroom -157483016
>> end_buffer 137 end_data 157483153
>>
>> There is nothing else that is modifying the packet before the function
>> call
>> or during the function call. I am clueless as to why the end_data and
>> end_buffer values are so weird. Any suggestions as to why this would be
>> happening would be really helpful.
>>
>> Thanks!
>>
>>


-- 
Amita Ekbote