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=<optimized out>) at
packet-ieee802154.c:1074
#4 0x00007f079ad5eae0 in call_dissector_through_handle
(handle=0x7f078fb55810, handle=0x7f078fb55810, data=0x0, 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=0x0)
at packet.c:759
#6 0x00007f079ad606f2 in call_dissector_with_data (handle=<optimized out>,
tvb=0x1000f20, pinfo=0x11b81c8, tree=0x1107410, data=<optimized out>)
at packet.c:3005
#7 0x00007f079b6afedc in dissect_zep (tvb=0x1000e80, pinfo=0x11b81c8,
tree=0x1107410, data=<optimized out>) at packet-zep.c:233
#8 0x00007f079ad5eae0 in call_dissector_through_handle
(handle=0x7f078e4482a0, handle=0x7f078e4482a0, data=0x0, 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=0x0)
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=0x0) 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=<optimized out>) at packet-udp.c:1137
#15 0x00007f079ad5eae0 in call_dissector_through_handle
(handle=0x7f078fb98210, handle=0x7f078fb98210, data=0x7f078b9d3350,
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=0x7f078b9d3350) 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=0x7f078b9d3350) 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=<optimized out>) at packet-ipv6.c:2366
#21 0x00007f079ad5eae0 in call_dissector_through_handle
(handle=0x7f078fb58b70, handle=0x7f078fb58b70, data=0x0, 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=0x0)
at packet.c:759
#23 0x00007f079ad606f2 in call_dissector_with_data (handle=<optimized out>,
tvb=0x11b72a0, pinfo=0x11b81c8, tree=0x1107410, data=<optimized out>)
at packet.c:3005
#24 0x00007f079b3f3075 in dissect_raw (tvb=0x11b72a0, pinfo=0x11b81c8,
tree=0x1107410, data=<optimized out>) at packet-raw.c:158
#25 0x00007f079ad5eae0 in call_dissector_through_handle
(handle=0x7f078fb8c3d0, handle=0x7f078fb8c3d0, data=0x1178548,
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=0x1178548) 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=0x1178548) at packet.c:1329
#28 0x00007f079b06f550 in dissect_frame (tvb=0x11b72a0, pinfo=0x11b81c8,
parent_tree=0x1107410, data=0x7ffd06021d60) at packet-frame.c:521
#29 0x00007f079ad5eae0 in call_dissector_through_handle
(handle=0x7f078fac6e10, handle=0x7f078fac6e10, data=0x7ffd06021d60,
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=0x7ffd06021d60) at packet.c:759
#31 0x00007f079ad606f2 in call_dissector_with_data (handle=<optimized out>,
tvb=0x11b72a0, pinfo=0x11b81c8, tree=0x1107410, data=<optimized 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 <pe...@lekensteyn.nl>:
> 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 <pe...@lekensteyn.nl>:
> >
> > > 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.keu...@xs4all.nl>:
> > > >
> > > > > 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.le...@inria.fr>
> 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@wireshark.org>
> Archives: https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=
> unsubscribe
>
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
