Home page logo

wireshark logo Wireshark mailing list archives

Re: OID/BER memory oddness
From: Ed Beroset <beroset () mindspring com>
Date: Sun, 15 Dec 2013 12:33:45 -0500

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.

Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]