|Main Archive Page > Month Archives > wireshark-dev archives|
Hi. Thanks for your reply.
I removed my assignment to this bit, but now things act funny.
For example, i am using the re-assembling mechanism, including the hash
I added DISSECTOR_ASSERTS for cases when the 'get' operation return a NULL.
This should never happen because I am inserting to the hash on the first
pass, using the 'visited' bit, and extracting from it on other passes
(visited != 0).
However, sometimes, not always, those asserts fails. If that's not odd
enough, saving to a file and re-loading it make the problems go away.
Maybe I don't really understand how the 'visited' bit works, or do I?
On Sun, May 16, 2010 at 7:16 PM, Jaap Keuter <email@example.com> wrote:
> On 05/16/2010 03:36 PM, Ari Yoskovitz wrote:
> > Hi.
> > I am using the pinfo->fd->flags.visited bit in my dissector.
> > I have discovered (after a lot of debugging...) the sometimes this bit
> > is asserted even on the first run, namely when the packet was not
> > It happens very rarely, but when it does the results are destructive.
> > Am I missing anything? Is this a bug?
> This should never happen. If this is true, that's a bug.
> Now the question is, can you define the circumstances when this happens?
> > Thanks.
> > BTW It looks to me that this bit has to be manually set to 1 when the
> > packet is being visited for the first time. Again, am I wrong here?
> This is *incorrect*
> The EPAN dissection engine handles setting of this bit after the frame was
> handed off to the frame dissector. See dissect_packet() in epan/packet.c.
> supposed to treat this as a readonly value. Maybe this is the cause for the
> you see?
> Sent via: Wireshark-dev mailing list <firstname.lastname@example.org>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
-- Use the source, Luke!
Sent via: Wireshark-dev mailing list <email@example.com>