ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 36988: /trunk/ /trunk/epan/dissector

From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
Date: Thu, 05 May 2011 09:27:40 -0400
Jakub Zawadzki wrote:
On Wed, May 04, 2011 at 04:40:12PM -0600, Stephen Fisher wrote:
On Wed, May 04, 2011 at 09:19:08PM +0000, darkjames@xxxxxxxxxxxxx wrote:

Log:
 XXX, should this code use g_try_malloc instead?
is that inside GTK+ and GLib, they still use g_malloc, so we can't totally eliminate the possibilty of Wireshark being aborted when out of memory.

Hmm, we could set our own allocator (g_mem_set_vtable()),
and THROW OutOfMemoryError (instead of aborting)

for example vtab.malloc routine:
#v+
static gpointer
ws_malloc(gsize n_bytes)
{
  gpointer ptr = malloc(n_bytes);
  if (!ptr)
    THROW(OutOfMemoryError);
  return ptr;
}
#v-

Is it likely/possible that:
a) GTK (or glib) might acquire a lock before allocating something
b) (and) we might call another GTK function which requires the same lock

thus leading to a deadlock if we jump out of the allocation failure?