Hi, Le jeudi 14 janvier 2010 à 17:37 +1100, Ian Schorr a écrit : > Hi Didier, > > On Thu, Jan 14, 2010 at 4:54 PM, didier <[email protected]> wrote: > > Hi, > > The whole file is first dissected sequentially with > > pinfo->fd->flags.visited set to FALSE. > > > > The most common error for what you're seeing is that the code is inside > > a if (tree) block, with the new packet list tree is null when loading a > > file, before it was null only with colors disable. > > > > You can test if it's the case by setting a filter like 'frame' and > > reloading the file with CTRL R. > > You're right - if I first open the capture, filter (with "frame") and > then reload, then looks like the flag is FALSE and the code block is > executed. > > This function itself never tests "if <tree or subtree>", and so far I > haven't found a situation where any of its parent functions in the > stack do this. There's so little difference between what NFSv3 and > NFSv4 dissecting is doing at this point, it seems unusual. But I'll > keep looking. Thanks for the tip. > > I'm still not clear on why your example is a problem though - what's > the logic error in doing this test during an "if (tree)" block? pinfo->fd->flags.visited is only FALSE the first time and the first time tree is null... thus in if (tree) if (!pinfo->fd->flags.visited) foo()
foo is never executed. same with: fitem = proto_add_uint( ...) if (!fitem) return offset offset = foo() return offset The bug could be a lot earlier though. The code you're looking at may not being called at all if a previous function return a wrong offset when tree is null, or it could be in the rpc code. Didier ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
