[Remy Leone <remy.leone@xxxxxxxx>]

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