https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16235
--- Comment #13 from Alexis La Goutte ---
(In reply to Nicolas Darchis from comment #12)
> is this fix comitted ?
No
--
You are receiving this mail because:
You are watching all bug
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16235
--- Comment #12 from Nicolas Darchis ---
is this fix comitted ?
--
You are receiving this mail because:
You are watching all bug changes.___
Sent via:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16235
--- Comment #11 from Gerrit Code Review ---
Change 35257 had a related patch set uploaded by Guy Harris:
Prevent idle dissection when a complete redissection is required.
https://code.wireshark.org/review/35257
--
You are receiving
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16235
--- Comment #10 from Guy Harris ---
(In reply to Guy Harris from comment #9)
> Right now, my guess is that the problem is that, when the Decode As dialog
> is OKed:
>
> in DecodeAsDialog::applyChanges(), the changes are applied to
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16235
Guy Harris changed:
What|Removed |Added
Component|Dissection engine |Qt UI
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16235
--- Comment #9 from Guy Harris ---
Right now, my guess is that the problem is that, when the Decode As dialog is
OKed:
in DecodeAsDialog::applyChanges(), the changes are applied to libwireshark's
decode tables, and then a
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16235
--- Comment #8 from Guy Harris ---
(In reply to Peter Wu from comment #7)
> For code like this:
>
> if (!PINFO_FD_VISITED(pinfo)) {
> p_add_proto_data(wmem_file_scope(), ...);
> } else {
> x =
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16235
--- Comment #7 from Peter Wu ---
For code like this:
if (!PINFO_FD_VISITED(pinfo)) {
p_add_proto_data(wmem_file_scope(), ...);
} else {
x = p_get_proto_data(wmem_file_scope(), ...);
}
You cannot assume x to be non-NULL in
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16235
--- Comment #6 from Guy Harris ---
(In reply to Peter Wu from comment #5)
> A compiler bug is a bit extreme, could it be a memory-safety issue? What if
> you build with cmake -DENABLE_ASAN=1?
Then it reports nothing other than the crash
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16235
--- Comment #5 from Peter Wu ---
A compiler bug is a bit extreme, could it be a memory-safety issue? What if you
build with cmake -DENABLE_ASAN=1?
--
You are receiving this mail because:
You are watching all bug
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16235
Guy Harris changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16235
--- Comment #3 from Guy Harris ---
The code where it fails is
/* this frame has already been seen, so get its info structure */
wlan_radio_info = (struct wlan_radio *) p_get_proto_data(wmem_file_scope(),
pinfo, proto_wlan_radio,
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16235
Alexis La Goutte changed:
What|Removed |Added
CC||alexis.lagou...@gmail.com,
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16235
--- Comment #2 from Nicolas Darchis ---
I have a capture file showing the problem. It's quite large (1 gig). I can
share privately with whoever works on the bug.
--
You are receiving this mail because:
You are watching all bug
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16235
--- Comment #1 from Nicolas Darchis ---
Created attachment 17488
--> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=17488=edit
crash details on mac os
--
You are receiving this mail because:
You are watching all bug
15 matches
Mail list logo
