[Pascal Quantin <pascal.quantin@xxxxxxxxx>]

Hi Rémy,

this seems similar to bug 13751 that you filled today and for which I provided a patch. Do you confirm it fixes your issue?

Cheers,

Pascal.

2017-06-01 17:18 GMT+02:00 Peter Wu <peter@xxxxxxxxxxxxx>:

Do you notice an infinite loop (increased CPU usage)? If that is the
case, you could interrupt several times, obtain a backtrace and
continue.

Tip: to limit to the last five frames use "bt 5" instead of "bt". For
more info about a command, use "help bt".

Note that if the program hangs or aborts abnormally during a live
capture, the temporary capture file can still be found in /tmp/. If you
can reproduce the problem with loading that pcap offline, then you can
be sure it is not related to the live capture (and it is likely a
dissector issue).

Kind regards,
Peter

On Thu, Jun 01, 2017 at 05:01:02PM +0200, Remy Leone wrote:
> Thanks a lot of the explaination :-)
> Here is the backtrace. I don't think Qt is involved.
>
> (gdb) bt
> #0  dissect_ieee802154_payload_mlme_sub_ie (offset=8, tree=0x7f078bbd4690,
> pinfo=0x11b81c8, tvb=0x1000f70) at packet-ieee802154.c:2628
> #1  dissect_ieee802154_payload_ie (offset=8, tree=<optimized out>,
> pinfo=0x11b81c8, tvb=0x1000f70) at packet-ieee802154.c:2912
> #2  dissect_ieee802154_common (tvb=0x1000f20, pinfo=pinfo@entry=0x11b81c8,
> tree=tree@entry=0x1107410, options=0) at packet-ieee802154.c:1783
> #3  0x00007f079b16d216 in dissect_ieee802154 (tvb=0x1000f20,
> pinfo=0x11b81c8, tree=0x1107410, data="" out>) at
> packet-ieee802154.c:1074
> #4  0x00007f079ad5eae0 in call_dissector_through_handle
> (handle=0x7f078fb55810, handle=0x7f078fb55810, data="" tree=0x1107410,
>     pinfo=0x11b81c8, tvb=0x1000f20) at packet.c:684
> #5  call_dissector_work (handle=0x7f078fb55810, tvb=0x1000f20,
> pinfo_arg=0x11b81c8, tree=0x1107410, add_proto_name=<optimized out>,
> data=""> >     at packet.c:759
> #6  0x00007f079ad606f2 in call_dissector_with_data (handle=<optimized out>,
> tvb=0x1000f20, pinfo=0x11b81c8, tree=0x1107410, data="" out>)
>     at packet.c:3005
> #7  0x00007f079b6afedc in dissect_zep (tvb=0x1000e80, pinfo=0x11b81c8,
> tree=0x1107410, data="" out>) at packet-zep.c:233
> #8  0x00007f079ad5eae0 in call_dissector_through_handle
> (handle=0x7f078e4482a0, handle=0x7f078e4482a0, data="" tree=0x1107410,
>     pinfo=0x11b81c8, tvb=0x1000e80) at packet.c:684
> #9  call_dissector_work (handle=0x7f078e4482a0, tvb=0x1000e80,
> pinfo_arg=0x11b81c8, tree=0x1107410, add_proto_name=<optimized out>,
> data=""> >     at packet.c:759
> #10 0x00007f079ad5f3d9 in dissector_try_uint_new (sub_dissectors=<optimized
> out>, uint_val=uint_val@entry=17754, tvb=tvb@entry=0x1000e80,
>     pinfo=pinfo@entry=0x11b81c8, tree=tree@entry=0x1107410,
> add_proto_name=add_proto_name@entry=1, data="" at packet.c:1329
> #11 0x00007f079ad5f421 in dissector_try_uint (sub_dissectors=<optimized
> out>, uint_val=uint_val@entry=17754, tvb=tvb@entry=0x1000e80,
>     pinfo=pinfo@entry=0x11b81c8, tree=tree@entry=0x1107410) at packet.c:1353
> #12 0x00007f079b5a7720 in decode_udp_ports (tvb=tvb@entry=0x1000ed0,
> offset=offset@entry=8, pinfo=pinfo@entry=0x11b81c8,
>     tree=tree@entry=0x1107410, uh_sport=<optimized out>,
> uh_dport=<optimized out>, uh_ulen=89) at packet-udp.c:678
> #13 0x00007f079b5a7de2 in dissect (tvb=tvb@entry=0x1000ed0,
> pinfo=0x11b81c8, tree=0x1107410, ip_proto=ip_proto@entry=17) at
> packet-udp.c:1131
> #14 0x00007f079b5a84de in dissect_udp (tvb=0x1000ed0, pinfo=<optimized
> out>, tree=<optimized out>, data="" out>) at packet-udp.c:1137
> #15 0x00007f079ad5eae0 in call_dissector_through_handle
> (handle=0x7f078fb98210, handle=0x7f078fb98210, data=""> > tree=0x1107410,
>     pinfo=0x11b81c8, tvb=0x1000ed0) at packet.c:684
> #16 call_dissector_work (handle=0x7f078fb98210, tvb=0x1000ed0,
> pinfo_arg=0x11b81c8, tree=0x1107410, add_proto_name=<optimized out>,
>     data="" at packet.c:759
> #17 0x00007f079ad5f3d9 in dissector_try_uint_new (sub_dissectors=<optimized
> out>, uint_val=17, tvb=0x1000ed0, pinfo=0x11b81c8, tree=0x1107410,
>     add_proto_name=add_proto_name@entry=1, data="" at
> packet.c:1329
> #18 0x00007f079b1818d8 in ip_try_dissect (heur_first=<optimized out>,
> nxt=nxt@entry=17, tvb=tvb@entry=0x1000ed0, pinfo=pinfo@entry=0x11b81c8,
>     tree=tree@entry=0x1107410, iph=0x7f078b9d3350) at packet-ip.c:1854
> #19 0x00007f079b1a0764 in ipv6_dissect_next (nxt=17, tvb=0x1000ed0,
> pinfo=0x11b81c8, tree=0x1107410, iph=<optimized out>) at packet-ipv6.c:2418
> #20 0x00007f079b1a10f1 in dissect_ipv6 (tvb=0x11b72a0, pinfo=0x11b81c8,
> tree=0x1107410, data="" out>) at packet-ipv6.c:2366
> #21 0x00007f079ad5eae0 in call_dissector_through_handle
> (handle=0x7f078fb58b70, handle=0x7f078fb58b70, data="" tree=0x1107410,
>     pinfo=0x11b81c8, tvb=0x11b72a0) at packet.c:684
> #22 call_dissector_work (handle=0x7f078fb58b70, tvb=0x11b72a0,
> pinfo_arg=0x11b81c8, tree=0x1107410, add_proto_name=<optimized out>,
> data=""> >     at packet.c:759
> #23 0x00007f079ad606f2 in call_dissector_with_data (handle=<optimized out>,
> tvb=0x11b72a0, pinfo=0x11b81c8, tree=0x1107410, data="" out>)
>     at packet.c:3005
> #24 0x00007f079b3f3075 in dissect_raw (tvb=0x11b72a0, pinfo=0x11b81c8,
> tree=0x1107410, data="" out>) at packet-raw.c:158
> #25 0x00007f079ad5eae0 in call_dissector_through_handle
> (handle=0x7f078fb8c3d0, handle=0x7f078fb8c3d0, data=""> > tree=0x1107410,
> ---Type <return> to continue, or q <return> to quit---bt
>     81c8, tvb=0x11b72a0) at packet.c:684
> #26 call_dissector_work (handle=0x7f078fb8c3d0, tvb=0x11b72a0,
> pinfo_arg=0x11b81c8, tree=0x1107410, add_proto_name=<optimized out>,
> data="" at packet.c:759
> #27 0x00007f079ad5f3d9 in dissector_try_uint_new (sub_dissectors=<optimized
> out>, uint_val=7, tvb=tvb@entry=0x11b72a0, pinfo=pinfo@entry=0x11b81c8,
> tree=tree@entry=0x1107410, add_proto_name=add_proto_name@entry=1,
>     data="" at packet.c:1329
> #28 0x00007f079b06f550 in dissect_frame (tvb=0x11b72a0, pinfo=0x11b81c8,
> parent_tree=0x1107410, data="" at packet-frame.c:521
> #29 0x00007f079ad5eae0 in call_dissector_through_handle
> (handle=0x7f078fac6e10, handle=0x7f078fac6e10, data=""> > tree=0x1107410, pinfo=0x11b81c8, tvb=0x11b72a0) at packet.c:684
> #30 call_dissector_work (handle=0x7f078fac6e10, tvb=0x11b72a0,
> pinfo_arg=0x11b81c8, tree=0x1107410, add_proto_name=<optimized out>,
> data="" at packet.c:759
> #31 0x00007f079ad606f2 in call_dissector_with_data (handle=<optimized out>,
> tvb=0x11b72a0, pinfo=0x11b81c8, tree=0x1107410, data="" out>) at
> packet.c:3005
> #32 0x00007f079ad60c2d in dissect_record (edt=edt@entry=0x11b81b0,
> file_type_subtype=file_type_subtype@entry=2, phdr=phdr@entry=0x11784e0,
> tvb=tvb@entry=0x11b72a0, fd=fd@entry=0x7ffd06021f20,
>     cinfo=cinfo@entry=0x644e60 <cfile+544>) at packet.c:567
> #33 0x00007f079ad53e64 in epan_dissect_run_with_taps (edt=edt@entry=0x11b81b0,
> file_type_subtype=2, phdr=phdr@entry=0x11784e0, tvb=0x11b72a0,
> fd=fd@entry=0x7ffd06021f20,
> cinfo=cinfo@entry=0x644e60 <cfile+544>)
>     at epan.c:473
> #34 0x0000000000417a5c in process_packet_single_pass (cf=cf@entry=0x644c40
> <cfile>, edt=edt@entry=0x11b81b0, offset=<optimized out>, whdr=0x11784e0,
> pd=pd@entry=0x117d4a0 "`", tap_flags=tap_flags@entry=0)
>     at tshark.c:3448
> #35 0x000000000040e9ec in process_cap_file (cf=0x644c40 <cfile>,
> max_byte_count=<optimized out>, max_packet_count=<optimized out>,
> out_file_name_res=<optimized out>, out_file_type=<optimized out>,
> save_file=0x0)
>     at tshark.c:3279
> #36 main (argc=<optimized out>, argv=<optimized out>) at tshark.c:1983
>
> Best regards
>
> Rémy
>
> 2017-06-01 16:54 GMT+02:00 Peter Wu <peter@xxxxxxxxxxxxx>:
>
> > You can attach to an existing process by its process ID:
> >
> >     gdb -q -p `pidof wireshark`
> >
> > then once attached, you can can obtain a backtrace with the "bt"
> > command. You can use "c" to continue and press Ctrl-C in gdb to
> > interrupt and enter commands like "bt".
> >
> > Kind regards,
> > Peter
> >
> > On Thu, Jun 01, 2017 at 04:33:49PM +0200, Remy Leone wrote:
> > > I'm not sure to understand. Wireshark doesn't crash but hangs in that
> > case.
> > > How could I get a symbolized stack trace?
> > >
> > > I've tried before to use libtool --mode=execute gdb ./wireshark but
> > > wireshark keeps hanging and I don't know how to use it to get meaningful
> > > information.
> > >
> > > Best regards
> > >
> > > Rémy
> > >
> > > 2017-06-01 16:24 GMT+02:00 Peter Wu <peter@xxxxxxxxxxxxx>:
> > >
> > > > It could be a bug in the Qt GUI component of Wireshark. Is it possible
> > > > to attach a debugger to "wireshark" or "dumpcap" and obtain a
> > symbolized
> > > > stack trace?
> > > >
> > > > Kind regards,
> > > > Peter
> > > >
> > > > On Tue, May 23, 2017 at 03:51:58PM +0200, Remy Leone wrote:
> > > > > I'm not sure about where to start investigating this issue. Where
> > does
> > > > the
> > > > > critical operation happen when wireshark/tshark is sniffing? I
> > suppose
> > > > that
> > > > > this is a problem of blocking read/write that is not happening
> > properly
> > > > but
> > > > > I'm not sure about how to get started to investigate this.
> > > > >
> > > > > 2017-05-23 10:35 GMT+02:00 Jaap Keuter <jaap.keuter@xxxxxxxxx>:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > You could inspect the bug database, but as far as I know this is
> > not a
> > > > > > known issue.
> > > > > > Your setup seems rather normal, so that should not be cause for any
> > > > > > problems.
> > > > > > If you could investigate further into tun / named pipe capture
> > > > behaviour
> > > > > > that could be interesting.
> > > > > >
> > > > > > Thanks,
> > > > > > Jaap
> > > > > >
> > > > > >
> > > > > > > On 23 May 2017, at 09:27, Remy Leone <remy.leone@xxxxxxxx>
> > wrote:
> > > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > I've stumbled upon the following problem with master branch of
> > > > > > Wireshark: After a while (around 10 minutes) Wireshark (master)
> > hangs
> > > > when
> > > > > > it's sniffing on a tun interface or a named pipe.
> > > > > > > On the other side, when I use the last stable version of
> > Wireshark
> > > > > > (2.2.6) I can sniff on the same interface or named pipe without
> > > > troubles
> > > > > > for a long time.
> > > > > > >
> > > > > > > Was there any change lately that would have caused that? I got
> > the
> > > > > > stable version of Wireshark installed through ubuntu
> > repository/ppa. My
> > > > > > user id also belongs to the wireshark group and I can sniff without
> > > > root
> > > > > > priviledges. Could the hanging be caused by that? Is that a
> > classical
> > > > > > problem?
> > > > > > >
> > > > > > > Best regards
> > > > > > >
> > > > > > > Rémy
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@wireshark.org?subject=unsubscribe