[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3046

Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jeff.morriss.ws@xxxxxxxxx

--- Comment #14 from Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> 2010-12-13 08:46:27 PST ---
Hmmm, I saw this problem today, but I suspect the root cause may be different. 
I list some info here just in case it's useful.

Config details: Solaris 10 SPARC, 1.4.2.  This build is using the (ancient)
glib and gtk that comes with Solaris 10:

~~~
Compiled (32-bit) with GTK+ 2.4.9, with GLib 2.4.1, with libpcap 1.1.1, with
libz 1.1.4, without POSIX capabilities, without libpcre, without SMI, without
c-ares, without ADNS, without Lua, without Python, without GnuTLS, without
Gcrypt, without Kerberos, without GeoIP, without PortAudio, without AirPcap.
NOTE: this build doesn't support the "matches" operator for Wireshark filter
syntax.

Running on SunOS 5.10, with libpcap version 1.1.1, with libz 1.2.3.

Built using gcc 3.4.3 (csl-sol210-3_4-branch+sol_rpath).
~~~

I was NOT capturing at all, let alone to multiple files; instead I was loading
a stored capture file (this one happens to be gzip'd).  After loading the file,
I noticed that Wireshark was a) extremely slow (to click around, etc.) and b)
using 100% of one core.

One attempt at a gcore didn't provide a usable backtrace.  Repeated pstack's
(Solaris has a native command for this that doesn't use gdb) showed:

 fb14bd3c _brk_unlocked (0, fb1b5678, 160dc48, 7c010, 160dc48, fc642a00) + 8
 fb134374 sbrk     (0, ffbfeeec, 7c050, fc82eec4, fb1b03a8, 18) + 24
 fb0d6d08 _morecore (2800, 160ca20, d902c, fb1b92ac, fb1b03a8, fb1b92a4) + 24
 fb0d662c _malloc_unlocked (2800, 160ca20, 1218, 160ca20, fb1b3910, 0) + 1fc
 fb0d675c realloc  (0, 2800, 0, 4, d9ccc, fc82fe80) + 88
 fc6dc544 g_realloc (0, 2800, fc840dc0, 0, fc70ec00, 2800) + 1c
 fc8212d4 pango_glyph_string_set_size (16082a0, 18f, 134, 0, fc840df8,
fc840dc0) + e0
 f8c90d78 basic_engine_shape (284ca0, c58188, c58188, 18f, f8ca1230, 16082a0) +
178
 fc838a38 pango_shape (15d7eb0, 18f, c95bec, 16082a0, fb1b03a8, 1d9ec) + 38
 fc82eec4 shape_run (1498d60, ffbfeeec, c95be0, 16082a0, fc72bc00, 18) + 6c
 fc82f028 process_item (15a3260, 1498d60, ffbfeeec, 1, 0, 80) + 44
 fc82f618 process_line (15a3260, ffbfeeec, 0, ffffffff, 0, fc8563f8) + 130
 fc82fe80 pango_layout_check_lines (ffbfeeec, 0, 15a3260, 15d7eb0, 0, 15d803f)
+ 364
 fc82dfcc pango_layout_get_extents_internal (15a3260, 0, ffbff0d8, 0, 28054,
400) + 64
 fc82e480 pango_layout_get_pixel_extents (15a3260, 0, ffbff0d8, 0, 27fe8,
fc97f6b4) + 78
 fc97f854 gtk_cell_renderer_text_get_size (b41280, b3a970, 0, 0, 0, ffbff1ac) +
184
 fc97b6e0 gtk_cell_renderer_get_size (b41280, b37f08, 0, 0, 0, fc97f6d0) + 134
 fcb1f494 gtk_tree_view_column_cell_get_size (b41300, 0, 0, 0, ffbff220,
ffbff21c) + 25c
 fcb0b270 validate_row (b3a970, cc4a08, 1225684, ffbff2a0, f, 0) + 108
 fcb0c48c do_validate_rows (b3a970, cc4a08, 1225684, 1489100, ffbff2a0, 0) +
2c0
 fcb0c790 validate_rows_handler (0, abac, d2ab8, fc6d57a0, a800, fcbdf210) + 44
 fc6d5ac8 g_main_dispatch (1d77b0, fc73ec00, 0, 0, fffffffd, ffffffef) + 19c
 fc6d6ffc g_main_context_dispatch (1d77b0, 1, 1c13bc, 0, fc73ec00, 1d77b0) + 9c
 fc6d74c8 g_main_context_iterate (1, 1, 1, 1d77b0, 1d77b8, 1) + 454
 fc6d7c44 g_main_loop_run (2644b8, fc73ec00, fc73edd0, 1e8b80, fc72a800,
fc72a800) + 348
 fca2aa2c gtk_main (0, 0, 2644b8, c7b3b8, fcbf2c18, 4cf8) + d0
 00050364 main     (19b400, 0, 0, 0, 0, 0) + e6c
 0002c3f8 _start   (0, 0, 0, 0, 0, 0) + 5c


truss showed that it was reading and re-reading the PCAP file (fd 7 is the PCAP
file):

brk(0x015B5C48)                                 = 0
read(7, "EF lC1 w wE0CE 2 ) : @ -".., 8192)     = 8192
read(7, "BFE0BDFD\vD1 7DE [A1 oA9".., 8192)     = 8192
brk(0x015B5C48)                                 = 0
brk(0x015B7C48)                                 = 0
brk(0x015B7C48)                                 = 0
brk(0x015B9C48)                                 = 0
ioctl(4, FIONREAD, 0xFFBFF2AC)                  = 0
pollsys(0x00288090, 1, 0xFFBFF370, 0x00000000)  = 0
ioctl(4, FIONREAD, 0xFFBFF2AC)                  = 0
pollsys(0x00288090, 1, 0xFFBFF370, 0x00000000)  = 0
brk(0x015B9C48)                                 = 0
brk(0x015BBC48)                                 = 0
brk(0x015BBC48)                                 = 0
brk(0x015BDC48)                                 = 0
read(7, "F9 sA2BAF3E8A58C16EB JCB".., 8192)     = 8192
read(7, "1C SC7 k1C pFF\nDC94F3 7".., 8192)     = 8192
brk(0x015BDC48)                                 = 0


If I then try to close the capture file (Ctrl-W), I get the hung "Closing
File!" dialog.  Wireshark continues to take 100% of one core and I get pstack's
that look like:

 fc6dc4e4 g_malloc0 (fc6dc460, fc73ec00, 271720, 46, fc73ee20, 44) + 1c
 fc7dbcd8 g_type_create_instance (255a58, 255a58, 271720, 271698, fc7feb30, 8)
+ 18c
 fc7c1bbc g_object_constructor (271698, 0, 0, 0, 2700, 0) + 4
 fc7c1158 g_object_newv (271698, fc7c1bb8, 0, 0, 271720, fc7e9800) + 328
 fc7c0d30 g_object_new (271698, 0, fc7c3ff8, 400, fc8563f8, fc7e9800) + 60
 fc82b320 pango_layout_new (c56940, f, c56940, fcb36354, fcbdf210, 9ebc) + 68
 fcb36538 gtk_widget_create_pango_layout (b3b1b0, 152bc60, 3007, a8d5c, 10,
fcbdf210) + 8c
 fc97f4f0 get_layout (b41ab8, b3b1b0, 0, 0, 102, 25fd50) + 38
 fc97f844 gtk_cell_renderer_text_get_size (b41ab8, b3b1b0, 0, 0, 0, ffbfddd4) +
174
 fc97b6e0 gtk_cell_renderer_get_size (b41ab8, b384b0, 0, 0, 0, fc97f6d0) + 134
 fcb1f494 gtk_tree_view_column_cell_get_size (b41b38, 0, 0, 0, ffbfde48,
ffbfde44) + 25c
 fcb0b270 validate_row (b3b1b0, d1e020, 1213b04, ffbfdec8, f, 0) + 108
 fcb0c48c do_validate_rows (b3b1b0, d1e020, 1213b04, 1475880, ffbfdec8, 0) +
2c0
 fcb0c790 validate_rows_handler (0, abac, d2ab8, fc6d57a0, a800, fcbdf210) + 44
 fc6d5ac8 g_main_dispatch (1d77b0, fc73ec00, 0, 0, fffffffd, ffffffef) + 19c
 fc6d6ffc g_main_context_dispatch (1d77b0, 1, 1c13bc, 0, fc73ec00, 1d77b0) + 9c
 fc6d74c8 g_main_context_iterate (1, 1, 1, 1d77b0, 1d77b8, 1) + 454
 fc6d76d8 g_main_context_iteration (0, fc73ec00, 1d77b0, 1d77b0, 0, ff28267c) +
94
 fca2accc gtk_main_iteration (0, 1b4580, fca2ac50, a800, fcbdf210, abd0) + 48
 0004a6a8 main_window_update (19b530, 19b530, 0, 0, 2700, 4f0a8) + 8
 000380b4 cf_callback_invoke (0, 19b530, 1eb320, 7, 50, 3) + 28
 0003be2c cf_close (19b530, 0, 0, a9d390, aaa678, c6aec) + 8
 fc7bdcd8 g_closure_invoke (ffbfe510, ffbfe3a4, 1, 10000, 0, aaa678) + 174
 fc7d54c8 signal_emit_unlocked_R (fc73ee24, fc7feaf8, fc73ee34, fc73ee20,
fc7feae4, 1eb438) + b70
 fc7d442c g_signal_emit_valist (a64908, aaaf20, 1eb438, ffbfe740, fc7feaf8,
fc73ee2c) + 7f8
 fc7d4738 g_signal_emit (a64908, 61, 0, acb24, fc7e0ed8, fcbf34ec) + 1c
 fcb327b0 closure_accel_activate (aab2d0, ffbfe888, 4, ffbfe9e0, ffbfe874, 1) +
20
 fc7bdcd8 g_closure_invoke (ffbfe9e0, ffbfe874, 4, 44020, 0, aab2d0) + 174
 fc7d54c8 signal_emit_unlocked_R (1, fc7feaf8, fc73ee34, fc73ee20, fc7feae4,
253cf8) + b70
 fc7d4484 g_signal_emit_valist (9fb830, 0, 253cf8, ffbfec1c, fc7feaf8,
fc7e8d20) + 850
 fc7d4738 g_signal_emit (9fb830, 55, 269, 1e36f0, 77, 4) + 1c
 fc95f2c8 gtk_accel_group_activate (fcbf229c, 269, 1e36f0, 77, 4, 0) + 100
 fc95f3b0 gtk_accel_groups_activate (1e36f0, 77, 4, 9a238, 27ff28, fcb450e0) +
d4
 fcb41608 gtk_window_key_press_event (1e36f0, 2c60b0, 1d7e50, 9dc1c, fc7e42c8,
fc7c4528) + 20
 fca2e060 _gtk_marshal_BOOLEAN__BOXED (ffbfee80, 1b129c, 1dc778, ffbfefd8,
ffbfee6c, fcb415e8) + f8
 fc7bdcd8 g_closure_invoke (ffbfefd8, ffbfee6c, 2, 18000, 0, 1dc778) + 174
 fc7d576c signal_emit_unlocked_R (1008, fc7feaf8, fc73ee34, fc73ee20, fc7feae4,
1dba30) + e14
 fc7d4484 g_signal_emit_valist (1e36f0, 0, 1dba30, ffbff20c, fc7feaf8,
fc7e8d20) + 850
 fc7d4738 g_signal_emit (1e36f0, 22, 0, 2c60b0, ffbff21c, fffffec8) + 1c
 fcb3398c gtk_widget_event_internal (1e36f0, 2c60b0, fcb33738, 18c, 24, 9c00) +
1cc
 fca2c668 gtk_propagate_event (1e36f0, 2c60b0, 1e36f0, 1b2d94, 1c1ef8,
fcbdf210) + 1f4
 fca2b4a0 gtk_main_do_event (368, 2c60b0, 0, fca2b110, 0, 24) + 308
 ff244dec gdk_event_dispatch (1cde30, 1cc088, 3a4e4, fc6d57a0, 2c60b0,
ff27f254) + 8c
 fc6d5ac8 g_main_dispatch (1d77b0, fc73ec00, 0, 0, fffffffd, ffffffef) + 19c
 fc6d6ffc g_main_context_dispatch (1d77b0, 1, 1c13bc, 0, fc73ec00, 1d77b0) + 9c
 fc6d74c8 g_main_context_iterate (1, 1, 1, 1d77b0, 1d77b8, 1) + 454
 fc6d7c44 g_main_loop_run (263ae0, fc73ec00, fc73edd0, 1e8b80, fc72a800,
fc72a800) + 348
 fca2aa2c gtk_main (0, 0, 263ae0, c7c0b8, fcbf2c18, 4cf8) + d0
 00050364 main     (19b400, 0, 0, 0, 0, 0) + e6c
 0002c3f8 _start   (0, 0, 0, 0, 0, 0) + 5c


My first thought is that I'm running into a GTK bug that's causing it to
repeatedly...  Select a row or something.  It MAY be related to the "multiple
files while Wireshark is minimized" scenario here if, for example, GTK is doing
something similar while Wireshark is minimized.

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