Hi, Still working on my block dissector. All works OK if the block size is less than 2KB but not for bigger blocks. The problem is that my registered block handler gets called with a wtapng_block that
has a frame data buffer with 2KB of allocated memory. This memory is allocated in file_access.c at this block of code: success: wth->rec_data = (struct Buffer *)g_malloc(sizeof(struct Buffer)); ws_buffer_init(wth->rec_data, 1500); ws_buffer_init looks like this: #define SMALL_BUFFER_SIZE (2 * 1024) /* Everyone still uses 1500 byte frames, right? */ static GPtrArray *small_buffers = NULL; /* Guaranteed to be at least SMALL_BUFFER_SIZE */ /* XXX - Add medium and large buffers? */ /* Initializes a buffer with a certain amount of allocated space */ void ws_buffer_init(Buffer* buffer, gsize space) { g_assert(buffer); if G_UNLIKELY(!small_buffers) small_buffers = g_ptr_array_sized_new(1024); if (space <= SMALL_BUFFER_SIZE) { if (small_buffers->len > 0) { buffer->data = "" g_ptr_array_remove_index(small_buffers, small_buffers->len - 1); } else { buffer->data = ""> } buffer->allocated = SMALL_BUFFER_SIZE; } else { buffer->data = ""> buffer->allocated = space; } buffer->start = 0; buffer->first_free = 0; } The ws_buffer_init is called specifying a space value of 1500 bytes and ws_buffer_init decides we just need a “small buffer” which is 2KB. It’s this 2KB buffer that I get in my block handler. I’m not sure what I am supposed to do at that point. Should my block handler just free the 2KB and then g_malloc a block of a suitable size? Thanks and regards…Paul ______________________________________________________________________ This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Advance Seven Ltd. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. Advance Seven Ltd. Registered in England & Wales numbered 2373877 at Endeavour House, Coopers End Lane, Stansted, Essex CM24 1SJ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ |
- Follow-Ups:
- Re: [Wireshark-dev] Frame Data Buffer Allocation
- From: Guy Harris
- Re: [Wireshark-dev] Frame Data Buffer Allocation
- Prev by Date: Re: [Wireshark-dev] New Block: Columns not Rendered in Packet List until rescan
- Next by Date: [Wireshark-dev] Submit code .... from Windows OS
- Previous by thread: Re: [Wireshark-dev] New Block: Columns not Rendered in Packet List until rescan
- Next by thread: Re: [Wireshark-dev] Frame Data Buffer Allocation
- Index(es):