Evan Huus
changed
bug 9984
Comment # 2
on bug 9984
from Evan Huus
No infinite loops or anything, just an excessive amount of memory. Massif
appears to blame se_address_to_str:
| ->56.23% (67,193,120B) 0x658A615: emem_alloc_glib (emem.c:884)
| | ->56.23% (67,193,120B) 0x658A84C: emem_alloc (emem.c:914)
| | ->56.17% (67,116,032B) 0x6582531: se_address_to_str
(address_to_str.c:550)
| | | ->56.17% (67,116,032B) 0x65809B3: se_get_addr_name (addr_resolv.c:3057)
| | | ->56.17% (67,116,032B) 0x6585BF3: col_set_addr.isra.4
(column-utils.c:1599)
| | | ->28.08% (33,558,016B) 0x6587EDB: col_fill_in (column-utils.c:1888)
| | | | ->28.08% (33,558,016B) 0x412ED4: print_packet (tshark.c:3902)
| | | | ->28.08% (33,558,016B) 0x413BB1: process_packet (tshark.c:3551)
| | | | ->28.08% (33,558,016B) 0x40B935: main (tshark.c:3327)
| | | |
| | | ->28.08% (33,558,016B) 0x6587FF6: col_fill_in (column-utils.c:1915)
| | | ->28.08% (33,558,016B) 0x412ED4: print_packet (tshark.c:3902)
| | | ->28.08% (33,558,016B) 0x413BB1: process_packet (tshark.c:3551)
| | | ->28.08% (33,558,016B) 0x40B935: main (tshark.c:3327)
| | |
| | ->00.06% (77,088B) in 1+ places, all below ms_print's threshold (01.00%)
| |
| ->10.62% (12,689,664B) 0x658A602: emem_alloc_glib (emem.c:882)
| | ->10.62% (12,689,664B) 0x658A84C: emem_alloc (emem.c:914)
| | ->10.53% (12,584,256B) 0x6582531: se_address_to_str
(address_to_str.c:550)
| | | ->10.53% (12,584,256B) 0x65809B3: se_get_addr_name (addr_resolv.c:3057)
| | | ->10.53% (12,584,256B) 0x6585BF3: col_set_addr.isra.4
(column-utils.c:1599)
| | | ->05.27% (6,292,128B) 0x6587EDB: col_fill_in (column-utils.c:1888)
| | | | ->05.27% (6,292,128B) 0x412ED4: print_packet (tshark.c:3902)
| | | | ->05.27% (6,292,128B) 0x413BB1: process_packet (tshark.c:3551)
| | | | ->05.27% (6,292,128B) 0x40B935: main (tshark.c:3327)
That memory probably doesn't need to persist for the whole scope of the file if
it's going to be printed and then forgotten...
You are receiving this mail because:
- You are watching all bug changes.