ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 8089] New Dissector - SEL (Schweitzer Engineering Laborato

Date: Tue, 18 Dec 2012 21:25:44 +0000

Comment # 16 on bug 8089 from
(In reply to comment #15)

> No, wmem should not be used with other glib memory functions, as wmem memory
> is not necessarily allocated via glib. The reason it continues to work is
> that you're never actually using it - you allocate wmem memory correctly and
> then immediately (on the very next line) reassign that variable to the
> result of  fmconfig_frame_fast, whose memory comes from glib still.
> 
> I expect most of the wmem work will be in fmconfig_frame_fast - all the
> calls to g_slice_new and g_array_* in that function should be replaced with
> similar or equivalent wmem calls. If wmem doesn't provide an exact
> equivalent it should be pretty easy to mimic with regular wmem_alloc()
> calls, or I can take a stab at adding to the wmem arsenal.
> 

I'm not seeing a whole lot of wmem examples through-out the source right now,
and the ones that are there (IP and smtp) seem to use a struct of hard-coded
size, without dynamically associated arrays.

What would be the wmem equivalent of g_array_append_val?  The issue I can see
right now is that at the beginning of running config_frame_fast, I know I of
course have a configuration frame.  Within that configuration frame, there will
be one cfg_data struct that has a variable length number of ai_info structs. 
Am I right in thinking that the existing wmem_alloc calls are good for
assigning a new chunk of memory, not-so-good at appending an existing one?  

I see there are some calls called "stacks" and "slabs" that could be referenced
in the wmem libraries, not sure if these are stacks I can dump data into and
then pull out of when required?

Ideally at the end of the day, what the selfm dissector needs is way to
store/retrieve a conversation with this structure:
- struct with pointers on any encountered config frames
- within the pointer to fast meter A5C1/C2/C3 frame, associated cfg_data and
dynamic ai information.

A A5D1, A5D2 or A5D3 frame needs to refer back to it's corresponding "C" frame,
so if there's a way in the new memory management library to do that, I'm all
ears.

Chris


You are receiving this mail because:
  • You are watching all bug changes.