Wireshark · Ethereal-dev: Re: [Ethereal-dev] Bug report for ethereal-0.10.10 on Fedora x86_64 version

[Pierre JUHEN <pierre.juhen@xxxxxxxxxx>]

Thanks, Guy,

I did your test.

capture_opts is ok and the same before and after cf_close.

I learned debuggers can lie, thanks...

Will continue to search tomorrow.

PJ



Guy Harris wrote :

> Are you inferring that because capture_opts is on the stack?
>
> If so, are you certain it's on the stack, rather than in a register?
>
> Optimizing compilers can make debuggers lie - it might be that 
> cf_close() is trashing the stack, but it might also be that 
> capture_opts is passed on the stack (from the pointers, I assume 
> you've compiled this in x86-64 mode rather than x86 mode; as x86-64 
> has, as I remember, 16 more-or-less general-purpose registers, C 
> compilers might be more likely to pass parameters in registers, but 
> perhaps the x86-64 ABI is modeled after the x86 ABI and has parameters 
> passed on the stack), but was loaded into a register and that the 
> debugger symbol table has it in the register in question - but that 
> the register in question isn't saved and restored by the caller or 
> callee, and is thus trashed, so that the generated code following the 
> cf_close() call will fetch it from the stack.
>
> You might want to try doing
>
> fprintf(stderr, "capture_opts %p\n", capture_opts);
>
> before and after the cf_close() call, to see whether its value is 
> getting trashed or if the debugger is just getting confused by the 
> optimized code.