https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4306
--- Comment #1 from Guy Harris <guy@xxxxxxxxxxxx> 2009-12-08 19:19:37 PST ---
The Red Hat Bugzilla entry for the bug in question is
https://bugzilla.redhat.com/show_bug.cgi?id=541377
A quick look at the code didn't show any obvious way for protocol_name to be
null in that case, unless some GLib routines not documented as returning null
do so.
In the first backtrace in that bug, build_autocompletion_list() was called from
filter_autocomplete_handle_backspace(), and the printout of the arguments to
build_autocompletion_list() doesn't show protocol_name being null (although
this is x86-64, so arguments can be passed in registers - but I'd expect gdb,
at least in theory, to warn that the argument value isn't available any more if
that register has been assigned to some other purpose).
The same is true of the other backtrace.
In the second backtrace, in the call to filter_string_te_key_pressed_cb(),
prefix_start is at 0x16f62f00 and has the value "!tcp.port==8470 &&
tcp.port==7023 && "; that string is 37 bytes long, not counting the terminating
'\0', which puts the terminating '\0' at 0x16f62f00+37, or 0x16f62f25. prefix
is at 0x16f62f26, so it points one byte *past* the terminating '\0'.
prefix gets passed to filter_autocomplete_handle_backspace() as the prefix
argument, and filter_autocomplete_handle_backspace() passes prefix to
build_autocompletion_list() as the protocol_name argument; the frame for
build_autocompletion_list() seems to show that as having happened.
The same - all the way down to "prefix is one byte past the end of
prefix_start's end" - is true in the first stack trace as well.
filter_autocomplete_handle_backspace(), if passed a null string, will trash the
byte before the '\0':
/* Delete the last character in the prefix string */
prefix_len = strlen(prefix)-1;
prefix[prefix_len] = '\0';
so, if that can happen, it probably needs to just return in that case.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
