http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1001
dgautheron@xxxxxxxx changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dgautheron@xxxxxxxx
------- Comment #10 from dgautheron@xxxxxxxx 2006-07-28 02:49 GMT -------
(In reply to comment #8)
> It turns out that the gdb backtrace was lying. I discovered this by changing
> except_free() in epan/except.c to this:
Yes, with optimization gdb doesn't always get the stack right.
> Something to note: The definition of ENDTRY has a line calling
> except_free(except_ch.except_obj.except_dyndata). According to the gdb
> backtrace, that value being passed is 0x0. Yet except_free() is reporting that
> the pointer it was passed is 0xbfb53db8. I wonder if I should just chalk this
> up to another case of gdb strangeness...
>
Maybe or:
--a bug in SSP gcc,
Can you attache the gdb output of
disas dissect_802_3
--Does valgrind work with SSP?
--Can you try to run it with all protocols below 802_3 disabled?
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.