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 <koh...@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
_______________________________________________
click mailing list
click@amsterdam.lcs.mit.edu
https://amsterdam.lcs.mit.edu/mailman/listinfo/click
