Wireshark-dev: Re: [Wireshark-dev] Patch for bug 1377 that produces a modal dialog with garbage
Peter Johansson wrote:
2007/3/30, Jeff Morriss <jeff.morriss@xxxxxxxxxxx
[...]
After having read the description for bug 1377 I agree. This patch fixes
that problem.
err_str should not be allocated prior to calling
get_airpcap_interface_list(&err, &err_str). err_str gets assigned a
pointer to allocated memory (g_strdup) in the called function that gets
freed when returning from the function.
Thank you for having me review my changes once more. It turns out that
my original change will make the code call g_free for the newly added
statically allocated error description which would be a new error.
I have attached a new set of files to be supplied as a solution for bug
1377. This time my changes allocate the error description using g_strdup
just like the rest of the code, making it possible to call g_free upon
return from the get_airpcap_interface_list(...) function.
I was also wondering how to handle this case, should it not produce a
dialogue at all? I am unsure. If a dialogue is not displayed, the user
will never understand why the AirPcap devices do not show up if AirPcap
is not loaded but Wireshark is compiled with support for it. On the
other hand, I guess most users do not have AirPcap, which means that it
would be annoying to get the dialogue every time when entering the
options dialogue.
It appears from the rest of the code that the intention is NOT to pop up
a dialog in this case (since it specifically checks to see if no
interfaces are found). The problem was if AirPcap is not loaded at all
then the error value is uninitialized so it could be 1--in which case
the dialog is popped up but with bogus contents.
Fixed in rev 21380 by simply setting the error value to a new value
(AIRPCAP_NOT_LOADED) so the caller knows not to pop up the dialog.
Presumably someone with airpcap.dll has to find out by some other means
that it's not being loaded properly.
