Wireshark-bugs: [Wireshark-bugs] [Bug 4115] 32-bit Wireshark crashes while opening large trace f
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.
