Evan Huus wrote:
In one sense the problem is easy to trace: the oid resolution code is
returning the resolved string in an ep-allocated buffer, which is then
getting freed and subsequently used. However, I'm having trouble
tracking down exactly where this resolved oid is being persisted
between packets, since the way I've followed the trace makes it look
like the oid resolution and subsequent use are happening in the same
packet, in which case it shouldn't be freed in the middle.
I'm hoping this will be obvious to somebody who actually knows the
BER/OID code. If not I'll file a bugzilla and attach the capture.
If you're asking what I think you're asking, as names get resolved,
they're added to a static tree called oid_root in oids.c. The children
of that tree are supposed to be in wmem_epan_scope(). There are three
oid_add functions that add items to that tree. One thing that may help
resolving this is to set the environment variable WIRESHARK_DEBUG_MIBS
to an integer value in the range 1 to 10. (Higher numbers mean more
verbose output.)
I'd like to have eliminated the ep_alloc() calls within oids.c in favor
of the newer wmem_ calls, but didn't have the time to do that properly
and it seemed that it might break other things. That's why I also added
the oid unit tests a few months ago.
If that doesn't help, let me know where I went astray and I can try again.
Ed
