Wireshark-bugs: [Wireshark-bugs] [Bug 4115] 32-bit Wireshark crashes while opening large trace f

Date: Mon, 26 Apr 2010 14:48:45 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4115

Guy Harris <guy@xxxxxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Platform|x86                         |All
            Summary|Wireshark crashes while     |32-bit Wireshark crashes
                   |opening large trace files   |while opening large trace
                   |on Mac OS X Snow Leopard    |files
         OS/Version|Mac OS X 10.6               |All

--- Comment #17 from Guy Harris <guy@xxxxxxxxxxxx> 2010-04-26 14:48:44 PDT ---
0   libSystem.B.dylib                 0x99001132 __kill + 10
1   libSystem.B.dylib                 0x99001124 kill$UNIX2003 + 32
2   libSystem.B.dylib                 0x990938e5 raise + 26
3   libSystem.B.dylib                 0x990a999c abort + 93
4   libglib-2.0.0.dylib               0x03749ad4 mem_error + 164
5   libglib-2.0.0.dylib               0x0374a0ab slab_allocator_alloc_chunk +
459
6   libglib-2.0.0.dylib               0x0374b61b g_slice_alloc + 1643

That looks like GLib's memory allocation code calling abort(), which it will do
if an attempt to allocate memory fails.  It probably just ran out of address
space.  (And it's allocating memory inside GTK+ for a row in the packet list,
so it's not Wireshark that's directly allocating that particular chunk of
memory.)

Nothing unique to Mac OS X about this (in fact, OS X keeps the kernel in a
separate address space, so you might actually have *more* room in OS X than,
say, Windows; I forget whether Linux/*BSD for various values of */Solaris/etc.
have separate kernel and user address spaces in 32-bit mode).

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.