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, darkja...@wireshark.org 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?
___________________________________________________________________________
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-requ...@wireshark.org?subject=unsubscribe
