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 <dgautheron@xxxxxxxx> 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
