osmith
/
wireshark
forked from osmocom/wireshark
1
0
Fork 0
Code Pull Requests Releases Wiki Activity
wireshark/wsutil/ws_pipe.c

859 lines
27 KiB
C
Raw Normal View History

Put special pipe-handling code into libwsutil. Ask, in a comment, why we're doing PeekNamedPipe() when we're trying to read everyting in the pipe, up to the EOF, into a string. On UN*X, do the same "read up to an EOF and then NUL-terminate the result" stuff that we did on Windows; nothing guarantees that, on all UN*Xes, in all circumstances, until the end of time, world without end, amen, we can do one read and get the entire string. Change-Id: I578802b23fec1051139eaefd9a09fe2a6de06a11 Reviewed-on: https://code.wireshark.org/review/24959 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Guy Harris <guy@alum.mit.edu>
2017-12-23 08:05:21 +00:00
/* ws_pipe.c
*
* Routines for handling pipes.
*
* Wireshark - Network traffic analyzer
* By Gerald Combs <gerald@wireshark.org>
* Copyright 1998 Gerald Combs
*
replace SPDX identifier GPL-2.0+ with GPL-2.0-or-later. The first is deprecated, as per https://spdx.org/licenses/. Change-Id: I8e21e1d32d09b8b94b93a2dc9fbdde5ffeba6bed Reviewed-on: https://code.wireshark.org/review/25661 Petri-Dish: Anders Broman <a.broman58@gmail.com> Petri-Dish: Dario Lombardo <lomato@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-02-07 11:26:45 +00:00
* SPDX-License-Identifier: GPL-2.0-or-later
Put special pipe-handling code into libwsutil. Ask, in a comment, why we're doing PeekNamedPipe() when we're trying to read everyting in the pipe, up to the EOF, into a string. On UN*X, do the same "read up to an EOF and then NUL-terminate the result" stuff that we did on Windows; nothing guarantees that, on all UN*Xes, in all circumstances, until the end of time, world without end, amen, we can do one read and get the entire string. Change-Id: I578802b23fec1051139eaefd9a09fe2a6de06a11 Reviewed-on: https://code.wireshark.org/review/24959 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Guy Harris <guy@alum.mit.edu>
2017-12-23 08:05:21 +00:00
*/
#include <config.h>
Refactor our logging and extend the wslog API Experience has shown that: 1. The current logging methods are not very reliable or practical. A logging bitmask makes little sense as the user-facing interface (who would want debug but not crtical messages for example?); it's computer-friendly and user-unfriendly. More importantly the console log level preference is initialized too late in the startup process to be used for the logging subsystem and that fact raises a number of annoying and hard-to-fix usability issues. 2. Coding around G_MESSAGES_DEBUG to comply with our log level mask and not clobber the user's settings or not create unexpected log misses is unworkable and generally follows the principle of most surprise. The fact that G_MESSAGES_DEBUG="all" can leak to other programs using GLib is also annoying. 3. The non-structured GLib logging API is very opinionated and lacks configurability beyond replacing the log handler. 4. Windows GUI has some special code to attach to a console, but it would be nice to abstract away the rest under a single interface. 5. Using this logger seems to be noticeably faster. Deprecate the console log level preference and extend our API to implement a log handler in wsutil/wslog.h to provide easy-to-use, flexible and dependable logging during all execution phases. Log levels have a hierarchy, from most verbose to least verbose (debug to error). When a given level is set everything above that is also enabled. The log level can be set with an environment variable or a command line option (parsed as soon as possible but still later than the environment). The default log level is "message". Dissector logging is not included because it is not clear what log domain they should use. An explosion to thousands of domains is not desirable and putting everything in a single domain is probably too coarse and noisy. For now I think it makes sense to let them do their own thing using g_log_default_handler() and continue using the G_MESSAGES_DEBUG mechanism with specific domains for each individual dissector. In the future a mechanism may be added to selectively enable these domains at runtime while trying to avoid the problems introduced by G_MESSAGES_DEBUG.
2021-06-08 01:46:52 +00:00
#define WS_LOG_DOMAIN LOG_DOMAIN_CAPTURE
Put special pipe-handling code into libwsutil. Ask, in a comment, why we're doing PeekNamedPipe() when we're trying to read everyting in the pipe, up to the EOF, into a string. On UN*X, do the same "read up to an EOF and then NUL-terminate the result" stuff that we did on Windows; nothing guarantees that, on all UN*Xes, in all circumstances, until the end of time, world without end, amen, we can do one read and get the entire string. Change-Id: I578802b23fec1051139eaefd9a09fe2a6de06a11 Reviewed-on: https://code.wireshark.org/review/24959 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Guy Harris <guy@alum.mit.edu>
2017-12-23 08:05:21 +00:00
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#ifdef _WIN32
#include <windows.h>
#include <io.h>
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
#include <fcntl.h> /* for _O_BINARY */
#include <wsutil/win32-utils.h>
Put special pipe-handling code into libwsutil. Ask, in a comment, why we're doing PeekNamedPipe() when we're trying to read everyting in the pipe, up to the EOF, into a string. On UN*X, do the same "read up to an EOF and then NUL-terminate the result" stuff that we did on Windows; nothing guarantees that, on all UN*Xes, in all circumstances, until the end of time, world without end, amen, we can do one read and get the entire string. Change-Id: I578802b23fec1051139eaefd9a09fe2a6de06a11 Reviewed-on: https://code.wireshark.org/review/24959 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Guy Harris <guy@alum.mit.edu>
2017-12-23 08:05:21 +00:00
#else
#include <unistd.h>
musl: compile with musl libc Ensure that wsutil/ws_pipe.c includes <sys/select.h> as as both the timeval struct and the select function are used. Change-Id: Idbd9e9a5b9cbee9977a423c32e55be81bb6425c3 Reviewed-on: https://code.wireshark.org/review/25616 Petri-Dish: Jaap Keuter <jaap.keuter@xs4all.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Guy Harris <guy@alum.mit.edu>
2018-02-07 03:22:22 +00:00
#ifdef HAVE_SYS_SELECT_H
#include <sys/select.h>
#endif
Put special pipe-handling code into libwsutil. Ask, in a comment, why we're doing PeekNamedPipe() when we're trying to read everyting in the pipe, up to the EOF, into a string. On UN*X, do the same "read up to an EOF and then NUL-terminate the result" stuff that we did on Windows; nothing guarantees that, on all UN*Xes, in all circumstances, until the end of time, world without end, amen, we can do one read and get the entire string. Change-Id: I578802b23fec1051139eaefd9a09fe2a6de06a11 Reviewed-on: https://code.wireshark.org/review/24959 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Guy Harris <guy@alum.mit.edu>
2017-12-23 08:05:21 +00:00
#endif
#include <glib.h>
ws_pipe_spawn_*: fix deadlock in g_spawn on Linux with threads The deadlock can be observed with a slow malloc implementation, e.g. ASAN_OPTIONS=fast_unwind_on_malloc=0 tshark --version (This calls extcap_run_all which uses threads and ws_pipe_spawn_sync.) Change-Id: Iff329c465c53ed177980368cd645f59222f88dd3 Reviewed-on: https://code.wireshark.org/review/30777 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-11-24 14:20:22 +00:00
#ifdef __linux__
#define HAS_G_SPAWN_LINUX_THREAD_SAFETY_BUG
#include <fcntl.h>
#include <sys/syscall.h> /* for syscall and SYS_getdents64 */
#include <wsutil/file_util.h> /* for ws_open -> open to pacify checkAPIs.pl */
#endif
Add ws_pipe_kill_child_on_exit. Add ws_pipe_kill_child_on_exit, which associates a child process handle with a job object that has the JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE flag set. Call it when we create a process in ws_pipe_spawn_sync and ws_pipe_spawn_async. Note that we might want to use it elsewhere. Change-Id: Ia0f6863ea4df0ab8623bb923a49da7776d83bd33 Reviewed-on: https://code.wireshark.org/review/26398 Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Gerald Combs <gerald@wireshark.org>
2018-03-09 18:25:40 +00:00
#include "wsutil/filesystem.h"
Put special pipe-handling code into libwsutil. Ask, in a comment, why we're doing PeekNamedPipe() when we're trying to read everyting in the pipe, up to the EOF, into a string. On UN*X, do the same "read up to an EOF and then NUL-terminate the result" stuff that we did on Windows; nothing guarantees that, on all UN*Xes, in all circumstances, until the end of time, world without end, amen, we can do one read and get the entire string. Change-Id: I578802b23fec1051139eaefd9a09fe2a6de06a11 Reviewed-on: https://code.wireshark.org/review/24959 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Guy Harris <guy@alum.mit.edu>
2017-12-23 08:05:21 +00:00
#include "wsutil/ws_pipe.h"
Refactor our logging and extend the wslog API Experience has shown that: 1. The current logging methods are not very reliable or practical. A logging bitmask makes little sense as the user-facing interface (who would want debug but not crtical messages for example?); it's computer-friendly and user-unfriendly. More importantly the console log level preference is initialized too late in the startup process to be used for the logging subsystem and that fact raises a number of annoying and hard-to-fix usability issues. 2. Coding around G_MESSAGES_DEBUG to comply with our log level mask and not clobber the user's settings or not create unexpected log misses is unworkable and generally follows the principle of most surprise. The fact that G_MESSAGES_DEBUG="all" can leak to other programs using GLib is also annoying. 3. The non-structured GLib logging API is very opinionated and lacks configurability beyond replacing the log handler. 4. Windows GUI has some special code to attach to a console, but it would be nice to abstract away the rest under a single interface. 5. Using this logger seems to be noticeably faster. Deprecate the console log level preference and extend our API to implement a log handler in wsutil/wslog.h to provide easy-to-use, flexible and dependable logging during all execution phases. Log levels have a hierarchy, from most verbose to least verbose (debug to error). When a given level is set everything above that is also enabled. The log level can be set with an environment variable or a command line option (parsed as soon as possible but still later than the environment). The default log level is "message". Dissector logging is not included because it is not clear what log domain they should use. An explosion to thousands of domains is not desirable and putting everything in a single domain is probably too coarse and noisy. For now I think it makes sense to let them do their own thing using g_log_default_handler() and continue using the G_MESSAGES_DEBUG mechanism with specific domains for each individual dissector. In the future a mechanism may be added to selectively enable these domains at runtime while trying to avoid the problems introduced by G_MESSAGES_DEBUG.
2021-06-08 01:46:52 +00:00
#include "wsutil/wslog.h"
Put special pipe-handling code into libwsutil. Ask, in a comment, why we're doing PeekNamedPipe() when we're trying to read everyting in the pipe, up to the EOF, into a string. On UN*X, do the same "read up to an EOF and then NUL-terminate the result" stuff that we did on Windows; nothing guarantees that, on all UN*Xes, in all circumstances, until the end of time, world without end, amen, we can do one read and get the entire string. Change-Id: I578802b23fec1051139eaefd9a09fe2a6de06a11 Reviewed-on: https://code.wireshark.org/review/24959 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Guy Harris <guy@alum.mit.edu>
2017-12-23 08:05:21 +00:00
ws_pipe_spawn_*: fix deadlock in g_spawn on Linux with threads The deadlock can be observed with a slow malloc implementation, e.g. ASAN_OPTIONS=fast_unwind_on_malloc=0 tshark --version (This calls extcap_run_all which uses threads and ws_pipe_spawn_sync.) Change-Id: Iff329c465c53ed177980368cd645f59222f88dd3 Reviewed-on: https://code.wireshark.org/review/30777 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-11-24 14:20:22 +00:00
#ifdef HAS_G_SPAWN_LINUX_THREAD_SAFETY_BUG
struct linux_dirent64 {
guint64 d_ino; /* 64-bit inode number */
guint64 d_off; /* 64-bit offset to next structure */
unsigned short d_reclen; /* Size of this dirent */
unsigned char d_type; /* File type */
char d_name[]; /* Filename (null-terminated) */
};
/* Async-signal-safe string to integer conversion. */
static gint
filename_to_fd(const char *p)
{
char c;
int fd = 0;
const int cutoff = G_MAXINT / 10;
const int cutlim = G_MAXINT % 10;
if (*p == '\0')
return -1;
while ((c = *p++) != '\0') {
if (!g_ascii_isdigit(c))
return -1;
c -= '0';
/* Check for overflow. */
if (fd > cutoff || (fd == cutoff && c > cutlim))
return -1;
fd = fd * 10 + c;
}
return fd;
}
static void
close_non_standard_fds_linux(gpointer user_data _U_)
{
/*
* GLib 2.14.2 and newer (up to at least GLib 2.58.1) on Linux with multiple
* threads can deadlock in the child process due to use of opendir (which
* is not async-signal-safe). To avoid this, disable the broken code path
* and manually close file descriptors using async-signal-safe code only.
* Use CLOEXEC to allow reporting of execve errors to the parent via a pipe.
* https://gitlab.gnome.org/GNOME/glib/issues/1014
* https://gitlab.gnome.org/GNOME/glib/merge_requests/490
*/
int dir_fd = ws_open("/proc/self/fd", O_RDONLY | O_DIRECTORY);
if (dir_fd >= 0) {
char buf[4096];
int nread, fd;
struct linux_dirent64 *de;
while ((nread = (int) syscall(SYS_getdents64, dir_fd, buf, sizeof(buf))) > 0) {
for (int pos = 0; pos < nread; pos += de->d_reclen) {
de = (struct linux_dirent64 *)(buf + pos);
fd = filename_to_fd(de->d_name);
if (fd > STDERR_FILENO && fd != dir_fd) {
/* Close all other (valid) file descriptors above stderr. */
fcntl(fd, F_SETFD, FD_CLOEXEC);
}
}
}
close(dir_fd);
} else {
/* Slow fallback in case /proc is not mounted */
for (int fd = STDERR_FILENO + 1; fd < getdtablesize(); fd++) {
fcntl(fd, F_SETFD, FD_CLOEXEC);
}
}
}
#endif
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
#ifdef _WIN32
static ULONG pipe_serial_number;
/* Alternative for CreatePipe() where read handle is opened with FILE_FLAG_OVERLAPPED */
static gboolean
ws_pipe_create_overlapped_read(HANDLE *read_pipe_handle, HANDLE *write_pipe_handle,
SECURITY_ATTRIBUTES *sa, DWORD suggested_buffer_size)
{
HANDLE read_pipe, write_pipe;
MinGW: Fix -Wformat
2023-01-12 03:43:59 +00:00
guchar *name = ws_strdup_printf("\\\\.\\Pipe\\WiresharkWsPipe.%08lx.%08lx",
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
GetCurrentProcessId(),
InterlockedIncrement(&pipe_serial_number));
gunichar2 *wname = g_utf8_to_utf16(name, -1, NULL, NULL, NULL);
g_free(name);
read_pipe = CreateNamedPipe(wname, PIPE_ACCESS_INBOUND | FILE_FLAG_OVERLAPPED,
PIPE_TYPE_BYTE | PIPE_WAIT, 1,
suggested_buffer_size, suggested_buffer_size,
0, sa);
Win32: Fix a return value check. CreateNamedPipe returns INVALID_HANDLE_VALUE on failure. Change-Id: I79ad5144e084520db8197b69c4ad34431d183009 Reviewed-on: https://code.wireshark.org/review/34704 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Guy Harris <guy@alum.mit.edu>
2019-10-03 19:24:26 +00:00
if (INVALID_HANDLE_VALUE == read_pipe)
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
{
g_free(wname);
return FALSE;
}
write_pipe = CreateFile(wname, GENERIC_WRITE, 0, sa, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
if (INVALID_HANDLE_VALUE == write_pipe)
{
DWORD error = GetLastError();
CloseHandle(read_pipe);
SetLastError(error);
g_free(wname);
return FALSE;
}
*read_pipe_handle = read_pipe;
*write_pipe_handle = write_pipe;
g_free(wname);
return(TRUE);
}
#endif
ws_pipe: fix memory leaks in spawn arguments handling On Windows, ws_pipe_spawn_sync always leaks 'winargs', and leaks 'argv' on some error paths. Fix these and refactor the common argument parsing functionality to reduce duplication of functionality. Change-Id: I8fa5ca45aec20b53f6fa243b0dd07241a345f7ab Reviewed-on: https://code.wireshark.org/review/32932 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Peter Wu <peter@lekensteyn.nl>
2019-04-21 18:48:11 +00:00
/**
* Helper to convert a command and argument list to an NULL-terminated 'argv'
* array, suitable for g_spawn_sync and friends. Free with g_strfreev.
*/
static gchar **
convert_to_argv(const char *command, int args_count, char *const *args)
{
gchar **argv = g_new(gchar *, args_count + 2);
// The caller does not seem to modify this, but g_spawn_sync uses 'gchar **'
// as opposed to 'const gchar **', so just to be sure clone it.
argv[0] = g_strdup(command);
for (int i = 0; i < args_count; i++) {
// Empty arguments may indicate a bug in Wireshark. Extcap for example
// omits arguments when their string value is empty. On Windows, empty
// arguments would silently be ignored because protect_arg returns an
// empty string, therefore we print a warning here.
if (!*args[i]) {
Refactor our logging and extend the wslog API Experience has shown that: 1. The current logging methods are not very reliable or practical. A logging bitmask makes little sense as the user-facing interface (who would want debug but not crtical messages for example?); it's computer-friendly and user-unfriendly. More importantly the console log level preference is initialized too late in the startup process to be used for the logging subsystem and that fact raises a number of annoying and hard-to-fix usability issues. 2. Coding around G_MESSAGES_DEBUG to comply with our log level mask and not clobber the user's settings or not create unexpected log misses is unworkable and generally follows the principle of most surprise. The fact that G_MESSAGES_DEBUG="all" can leak to other programs using GLib is also annoying. 3. The non-structured GLib logging API is very opinionated and lacks configurability beyond replacing the log handler. 4. Windows GUI has some special code to attach to a console, but it would be nice to abstract away the rest under a single interface. 5. Using this logger seems to be noticeably faster. Deprecate the console log level preference and extend our API to implement a log handler in wsutil/wslog.h to provide easy-to-use, flexible and dependable logging during all execution phases. Log levels have a hierarchy, from most verbose to least verbose (debug to error). When a given level is set everything above that is also enabled. The log level can be set with an environment variable or a command line option (parsed as soon as possible but still later than the environment). The default log level is "message". Dissector logging is not included because it is not clear what log domain they should use. An explosion to thousands of domains is not desirable and putting everything in a single domain is probably too coarse and noisy. For now I think it makes sense to let them do their own thing using g_log_default_handler() and continue using the G_MESSAGES_DEBUG mechanism with specific domains for each individual dissector. In the future a mechanism may be added to selectively enable these domains at runtime while trying to avoid the problems introduced by G_MESSAGES_DEBUG.
2021-06-08 01:46:52 +00:00
ws_warning("Empty argument %d in arguments list", i);
ws_pipe: fix memory leaks in spawn arguments handling On Windows, ws_pipe_spawn_sync always leaks 'winargs', and leaks 'argv' on some error paths. Fix these and refactor the common argument parsing functionality to reduce duplication of functionality. Change-Id: I8fa5ca45aec20b53f6fa243b0dd07241a345f7ab Reviewed-on: https://code.wireshark.org/review/32932 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Peter Wu <peter@lekensteyn.nl>
2019-04-21 18:48:11 +00:00
}
argv[1 + i] = g_strdup(args[i]);
}
argv[args_count + 1] = NULL;
return argv;
}
/**
* Convert a non-empty NULL-terminated array of command and arguments to a
* string for displaying purposes. On Windows, the returned string is properly
* escaped and can be executed directly.
*/
static gchar *
convert_to_command_line(gchar **argv)
{
GString *command_line = g_string_sized_new(200);
#ifdef _WIN32
// The first argument must always be quoted even if it does not contain
// special characters or else CreateProcess might consider arguments as part
// of the executable.
gchar *quoted_arg = protect_arg(argv[0]);
if (quoted_arg[0] != '"') {
g_string_append_c(command_line, '"');
g_string_append(command_line, quoted_arg);
g_string_append_c(command_line, '"');
} else {
g_string_append(command_line, quoted_arg);
}
g_free(quoted_arg);
for (int i = 1; argv[i]; i++) {
quoted_arg = protect_arg(argv[i]);
g_string_append_c(command_line, ' ');
g_string_append(command_line, quoted_arg);
g_free(quoted_arg);
}
#else
for (int i = 0; argv[i]; i++) {
gchar *quoted_arg = g_shell_quote(argv[i]);
if (i != 0) {
g_string_append_c(command_line, ' ');
}
g_string_append(command_line, quoted_arg);
g_free(quoted_arg);
}
#endif
return g_string_free(command_line, FALSE);
}
ws_pipe_spawn_sync: mark arguments as const where possible This avoids an unnecessary explicit cast. For clarity, rename the working directory argument to match g_spawn_sync. Change-Id: Idf7072cd590e686294d953f77da2a52c861a89c0 Reviewed-on: https://code.wireshark.org/review/30763 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-11-22 15:45:41 +00:00
gboolean ws_pipe_spawn_sync(const gchar *working_directory, const gchar *command, gint argc, gchar **args, gchar **command_output)
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
{
gboolean status = FALSE;
gboolean result = FALSE;
gchar *local_output = NULL;
#ifdef _WIN32
#define BUFFER_SIZE 16384
STARTUPINFO info;
PROCESS_INFORMATION processInfo;
SECURITY_ATTRIBUTES sa;
HANDLE child_stdout_rd = NULL;
HANDLE child_stdout_wr = NULL;
HANDLE child_stderr_rd = NULL;
HANDLE child_stderr_wr = NULL;
win32-utils: Explicitly list inherited handles Windows processes inherit all inheritable handles when a new process is created using CreateProcess() with bInheritHandles set to TRUE. This can lead to undesired object lifetime extension. That is, the child process will keep ineritable handles alive even if it does not use them. Up to Windows Vista it was not possible explicitly list handles that should be inherited. Wireshark no longer works on Windows releases earlier than Vista, so use the new API without checking Windows version. Require all callers to win32_create_process() to pass in the list of handles to inherit. Set the listed handles as inheritable shortly before calling CreateProcess() and set them as not inheritable shortly after the process is created. This minimizes possibility for other callers (especially in 3rd party libraries) to inherit handles by accident. Do not terminate mmdbresolve process on exit. Instead rely on process exit when EOF is received on standard input. Previously the EOF was never received because mmdbresolve inherited both ends of standard input pipe, i.e. the fact that Wireshark closed the write end was not observed by mmdbresolve because mmdbresolve kept write handle the standard input pipe open.
2022-08-15 08:51:20 +00:00
HANDLE inherit_handles[2];
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
OVERLAPPED stdout_overlapped;
OVERLAPPED stderr_overlapped;
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
#else
gint exit_status = 0;
#endif
ws_pipe: fix memory leaks in spawn arguments handling On Windows, ws_pipe_spawn_sync always leaks 'winargs', and leaks 'argv' on some error paths. Fix these and refactor the common argument parsing functionality to reduce duplication of functionality. Change-Id: I8fa5ca45aec20b53f6fa243b0dd07241a345f7ab Reviewed-on: https://code.wireshark.org/review/32932 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Peter Wu <peter@lekensteyn.nl>
2019-04-21 18:48:11 +00:00
gchar **argv = convert_to_argv(command, argc, args);
gchar *command_line = convert_to_command_line(argv);
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
Refactor our logging and extend the wslog API Experience has shown that: 1. The current logging methods are not very reliable or practical. A logging bitmask makes little sense as the user-facing interface (who would want debug but not crtical messages for example?); it's computer-friendly and user-unfriendly. More importantly the console log level preference is initialized too late in the startup process to be used for the logging subsystem and that fact raises a number of annoying and hard-to-fix usability issues. 2. Coding around G_MESSAGES_DEBUG to comply with our log level mask and not clobber the user's settings or not create unexpected log misses is unworkable and generally follows the principle of most surprise. The fact that G_MESSAGES_DEBUG="all" can leak to other programs using GLib is also annoying. 3. The non-structured GLib logging API is very opinionated and lacks configurability beyond replacing the log handler. 4. Windows GUI has some special code to attach to a console, but it would be nice to abstract away the rest under a single interface. 5. Using this logger seems to be noticeably faster. Deprecate the console log level preference and extend our API to implement a log handler in wsutil/wslog.h to provide easy-to-use, flexible and dependable logging during all execution phases. Log levels have a hierarchy, from most verbose to least verbose (debug to error). When a given level is set everything above that is also enabled. The log level can be set with an environment variable or a command line option (parsed as soon as possible but still later than the environment). The default log level is "message". Dissector logging is not included because it is not clear what log domain they should use. An explosion to thousands of domains is not desirable and putting everything in a single domain is probably too coarse and noisy. For now I think it makes sense to let them do their own thing using g_log_default_handler() and continue using the G_MESSAGES_DEBUG mechanism with specific domains for each individual dissector. In the future a mechanism may be added to selectively enable these domains at runtime while trying to avoid the problems introduced by G_MESSAGES_DEBUG.
2021-06-08 01:46:52 +00:00
ws_debug("command line: %s", command_line);
Allow trace of sync spawns When Wireshark uses a synchronous spawn (e.g., to launch an extcap) it would be nice to be able to see what command line is constructed to launch the process, and to see what comes back. The output will go to the g_log. Change-Id: Iec6baeebc026cd80398084c9644fc916ab068e2f Reviewed-on: https://code.wireshark.org/review/30475 Petri-Dish: Dario Lombardo <lomato@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Peter Wu <peter@lekensteyn.nl>
2018-11-01 16:20:47 +00:00
ws_pipe_spawn_sync: debug log elapsed time Tested with `G_MESSAGES_DEBUG=all tshark --version`. Change-Id: Iae525b9de197f012c21693a91155f931d4dcc1f7 Ping-Bug: 15295 Reviewed-on: https://code.wireshark.org/review/30759 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-11-22 10:29:03 +00:00
guint64 start_time = g_get_monotonic_time();
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
#ifdef _WIN32
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
/* Setup overlapped structures. Create Manual Reset events, initially not signalled */
memset(&stdout_overlapped, 0, sizeof(OVERLAPPED));
memset(&stderr_overlapped, 0, sizeof(OVERLAPPED));
stdout_overlapped.hEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
if (!stdout_overlapped.hEvent)
{
ws_pipe: fix memory leaks in spawn arguments handling On Windows, ws_pipe_spawn_sync always leaks 'winargs', and leaks 'argv' on some error paths. Fix these and refactor the common argument parsing functionality to reduce duplication of functionality. Change-Id: I8fa5ca45aec20b53f6fa243b0dd07241a345f7ab Reviewed-on: https://code.wireshark.org/review/32932 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Peter Wu <peter@lekensteyn.nl>
2019-04-21 18:48:11 +00:00
g_free(command_line);
g_strfreev(argv);
Refactor our logging and extend the wslog API Experience has shown that: 1. The current logging methods are not very reliable or practical. A logging bitmask makes little sense as the user-facing interface (who would want debug but not crtical messages for example?); it's computer-friendly and user-unfriendly. More importantly the console log level preference is initialized too late in the startup process to be used for the logging subsystem and that fact raises a number of annoying and hard-to-fix usability issues. 2. Coding around G_MESSAGES_DEBUG to comply with our log level mask and not clobber the user's settings or not create unexpected log misses is unworkable and generally follows the principle of most surprise. The fact that G_MESSAGES_DEBUG="all" can leak to other programs using GLib is also annoying. 3. The non-structured GLib logging API is very opinionated and lacks configurability beyond replacing the log handler. 4. Windows GUI has some special code to attach to a console, but it would be nice to abstract away the rest under a single interface. 5. Using this logger seems to be noticeably faster. Deprecate the console log level preference and extend our API to implement a log handler in wsutil/wslog.h to provide easy-to-use, flexible and dependable logging during all execution phases. Log levels have a hierarchy, from most verbose to least verbose (debug to error). When a given level is set everything above that is also enabled. The log level can be set with an environment variable or a command line option (parsed as soon as possible but still later than the environment). The default log level is "message". Dissector logging is not included because it is not clear what log domain they should use. An explosion to thousands of domains is not desirable and putting everything in a single domain is probably too coarse and noisy. For now I think it makes sense to let them do their own thing using g_log_default_handler() and continue using the G_MESSAGES_DEBUG mechanism with specific domains for each individual dissector. In the future a mechanism may be added to selectively enable these domains at runtime while trying to avoid the problems introduced by G_MESSAGES_DEBUG.
2021-06-08 01:46:52 +00:00
ws_debug("Could not create stdout overlapped event");
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
return FALSE;
}
stderr_overlapped.hEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
if (!stderr_overlapped.hEvent)
{
CloseHandle(stdout_overlapped.hEvent);
ws_pipe: fix memory leaks in spawn arguments handling On Windows, ws_pipe_spawn_sync always leaks 'winargs', and leaks 'argv' on some error paths. Fix these and refactor the common argument parsing functionality to reduce duplication of functionality. Change-Id: I8fa5ca45aec20b53f6fa243b0dd07241a345f7ab Reviewed-on: https://code.wireshark.org/review/32932 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Peter Wu <peter@lekensteyn.nl>
2019-04-21 18:48:11 +00:00
g_free(command_line);
g_strfreev(argv);
Refactor our logging and extend the wslog API Experience has shown that: 1. The current logging methods are not very reliable or practical. A logging bitmask makes little sense as the user-facing interface (who would want debug but not crtical messages for example?); it's computer-friendly and user-unfriendly. More importantly the console log level preference is initialized too late in the startup process to be used for the logging subsystem and that fact raises a number of annoying and hard-to-fix usability issues. 2. Coding around G_MESSAGES_DEBUG to comply with our log level mask and not clobber the user's settings or not create unexpected log misses is unworkable and generally follows the principle of most surprise. The fact that G_MESSAGES_DEBUG="all" can leak to other programs using GLib is also annoying. 3. The non-structured GLib logging API is very opinionated and lacks configurability beyond replacing the log handler. 4. Windows GUI has some special code to attach to a console, but it would be nice to abstract away the rest under a single interface. 5. Using this logger seems to be noticeably faster. Deprecate the console log level preference and extend our API to implement a log handler in wsutil/wslog.h to provide easy-to-use, flexible and dependable logging during all execution phases. Log levels have a hierarchy, from most verbose to least verbose (debug to error). When a given level is set everything above that is also enabled. The log level can be set with an environment variable or a command line option (parsed as soon as possible but still later than the environment). The default log level is "message". Dissector logging is not included because it is not clear what log domain they should use. An explosion to thousands of domains is not desirable and putting everything in a single domain is probably too coarse and noisy. For now I think it makes sense to let them do their own thing using g_log_default_handler() and continue using the G_MESSAGES_DEBUG mechanism with specific domains for each individual dissector. In the future a mechanism may be added to selectively enable these domains at runtime while trying to avoid the problems introduced by G_MESSAGES_DEBUG.
2021-06-08 01:46:52 +00:00
ws_debug("Could not create stderr overlapped event");
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
return FALSE;
}
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
memset(&sa, 0, sizeof(SECURITY_ATTRIBUTES));
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
sa.nLength = sizeof(SECURITY_ATTRIBUTES);
win32-utils: Explicitly list inherited handles Windows processes inherit all inheritable handles when a new process is created using CreateProcess() with bInheritHandles set to TRUE. This can lead to undesired object lifetime extension. That is, the child process will keep ineritable handles alive even if it does not use them. Up to Windows Vista it was not possible explicitly list handles that should be inherited. Wireshark no longer works on Windows releases earlier than Vista, so use the new API without checking Windows version. Require all callers to win32_create_process() to pass in the list of handles to inherit. Set the listed handles as inheritable shortly before calling CreateProcess() and set them as not inheritable shortly after the process is created. This minimizes possibility for other callers (especially in 3rd party libraries) to inherit handles by accident. Do not terminate mmdbresolve process on exit. Instead rely on process exit when EOF is received on standard input. Previously the EOF was never received because mmdbresolve inherited both ends of standard input pipe, i.e. the fact that Wireshark closed the write end was not observed by mmdbresolve because mmdbresolve kept write handle the standard input pipe open.
2022-08-15 08:51:20 +00:00
sa.bInheritHandle = FALSE;
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
sa.lpSecurityDescriptor = NULL;
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
if (!ws_pipe_create_overlapped_read(&child_stdout_rd, &child_stdout_wr, &sa, 0))
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
{
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
CloseHandle(stdout_overlapped.hEvent);
CloseHandle(stderr_overlapped.hEvent);
ws_pipe: fix memory leaks in spawn arguments handling On Windows, ws_pipe_spawn_sync always leaks 'winargs', and leaks 'argv' on some error paths. Fix these and refactor the common argument parsing functionality to reduce duplication of functionality. Change-Id: I8fa5ca45aec20b53f6fa243b0dd07241a345f7ab Reviewed-on: https://code.wireshark.org/review/32932 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Peter Wu <peter@lekensteyn.nl>
2019-04-21 18:48:11 +00:00
g_free(command_line);
g_strfreev(argv);
Refactor our logging and extend the wslog API Experience has shown that: 1. The current logging methods are not very reliable or practical. A logging bitmask makes little sense as the user-facing interface (who would want debug but not crtical messages for example?); it's computer-friendly and user-unfriendly. More importantly the console log level preference is initialized too late in the startup process to be used for the logging subsystem and that fact raises a number of annoying and hard-to-fix usability issues. 2. Coding around G_MESSAGES_DEBUG to comply with our log level mask and not clobber the user's settings or not create unexpected log misses is unworkable and generally follows the principle of most surprise. The fact that G_MESSAGES_DEBUG="all" can leak to other programs using GLib is also annoying. 3. The non-structured GLib logging API is very opinionated and lacks configurability beyond replacing the log handler. 4. Windows GUI has some special code to attach to a console, but it would be nice to abstract away the rest under a single interface. 5. Using this logger seems to be noticeably faster. Deprecate the console log level preference and extend our API to implement a log handler in wsutil/wslog.h to provide easy-to-use, flexible and dependable logging during all execution phases. Log levels have a hierarchy, from most verbose to least verbose (debug to error). When a given level is set everything above that is also enabled. The log level can be set with an environment variable or a command line option (parsed as soon as possible but still later than the environment). The default log level is "message". Dissector logging is not included because it is not clear what log domain they should use. An explosion to thousands of domains is not desirable and putting everything in a single domain is probably too coarse and noisy. For now I think it makes sense to let them do their own thing using g_log_default_handler() and continue using the G_MESSAGES_DEBUG mechanism with specific domains for each individual dissector. In the future a mechanism may be added to selectively enable these domains at runtime while trying to avoid the problems introduced by G_MESSAGES_DEBUG.
2021-06-08 01:46:52 +00:00
ws_debug("Could not create stdout handle");
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
return FALSE;
}
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
if (!ws_pipe_create_overlapped_read(&child_stderr_rd, &child_stderr_wr, &sa, 0))
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
{
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
CloseHandle(stdout_overlapped.hEvent);
CloseHandle(stderr_overlapped.hEvent);
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
CloseHandle(child_stdout_rd);
CloseHandle(child_stdout_wr);
ws_pipe: fix memory leaks in spawn arguments handling On Windows, ws_pipe_spawn_sync always leaks 'winargs', and leaks 'argv' on some error paths. Fix these and refactor the common argument parsing functionality to reduce duplication of functionality. Change-Id: I8fa5ca45aec20b53f6fa243b0dd07241a345f7ab Reviewed-on: https://code.wireshark.org/review/32932 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Peter Wu <peter@lekensteyn.nl>
2019-04-21 18:48:11 +00:00
g_free(command_line);
g_strfreev(argv);
Refactor our logging and extend the wslog API Experience has shown that: 1. The current logging methods are not very reliable or practical. A logging bitmask makes little sense as the user-facing interface (who would want debug but not crtical messages for example?); it's computer-friendly and user-unfriendly. More importantly the console log level preference is initialized too late in the startup process to be used for the logging subsystem and that fact raises a number of annoying and hard-to-fix usability issues. 2. Coding around G_MESSAGES_DEBUG to comply with our log level mask and not clobber the user's settings or not create unexpected log misses is unworkable and generally follows the principle of most surprise. The fact that G_MESSAGES_DEBUG="all" can leak to other programs using GLib is also annoying. 3. The non-structured GLib logging API is very opinionated and lacks configurability beyond replacing the log handler. 4. Windows GUI has some special code to attach to a console, but it would be nice to abstract away the rest under a single interface. 5. Using this logger seems to be noticeably faster. Deprecate the console log level preference and extend our API to implement a log handler in wsutil/wslog.h to provide easy-to-use, flexible and dependable logging during all execution phases. Log levels have a hierarchy, from most verbose to least verbose (debug to error). When a given level is set everything above that is also enabled. The log level can be set with an environment variable or a command line option (parsed as soon as possible but still later than the environment). The default log level is "message". Dissector logging is not included because it is not clear what log domain they should use. An explosion to thousands of domains is not desirable and putting everything in a single domain is probably too coarse and noisy. For now I think it makes sense to let them do their own thing using g_log_default_handler() and continue using the G_MESSAGES_DEBUG mechanism with specific domains for each individual dissector. In the future a mechanism may be added to selectively enable these domains at runtime while trying to avoid the problems introduced by G_MESSAGES_DEBUG.
2021-06-08 01:46:52 +00:00
ws_debug("Could not create stderr handle");
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
return FALSE;
}
win32-utils: Explicitly list inherited handles Windows processes inherit all inheritable handles when a new process is created using CreateProcess() with bInheritHandles set to TRUE. This can lead to undesired object lifetime extension. That is, the child process will keep ineritable handles alive even if it does not use them. Up to Windows Vista it was not possible explicitly list handles that should be inherited. Wireshark no longer works on Windows releases earlier than Vista, so use the new API without checking Windows version. Require all callers to win32_create_process() to pass in the list of handles to inherit. Set the listed handles as inheritable shortly before calling CreateProcess() and set them as not inheritable shortly after the process is created. This minimizes possibility for other callers (especially in 3rd party libraries) to inherit handles by accident. Do not terminate mmdbresolve process on exit. Instead rely on process exit when EOF is received on standard input. Previously the EOF was never received because mmdbresolve inherited both ends of standard input pipe, i.e. the fact that Wireshark closed the write end was not observed by mmdbresolve because mmdbresolve kept write handle the standard input pipe open.
2022-08-15 08:51:20 +00:00
inherit_handles[0] = child_stderr_wr;
inherit_handles[1] = child_stdout_wr;
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
memset(&processInfo, 0, sizeof(PROCESS_INFORMATION));
memset(&info, 0, sizeof(STARTUPINFO));
info.cb = sizeof(STARTUPINFO);
info.hStdError = child_stderr_wr;
info.hStdOutput = child_stdout_wr;
info.dwFlags = STARTF_USESTDHANDLES | STARTF_USESHOWWINDOW;
info.wShowWindow = SW_HIDE;
win32-utils: Explicitly list inherited handles Windows processes inherit all inheritable handles when a new process is created using CreateProcess() with bInheritHandles set to TRUE. This can lead to undesired object lifetime extension. That is, the child process will keep ineritable handles alive even if it does not use them. Up to Windows Vista it was not possible explicitly list handles that should be inherited. Wireshark no longer works on Windows releases earlier than Vista, so use the new API without checking Windows version. Require all callers to win32_create_process() to pass in the list of handles to inherit. Set the listed handles as inheritable shortly before calling CreateProcess() and set them as not inheritable shortly after the process is created. This minimizes possibility for other callers (especially in 3rd party libraries) to inherit handles by accident. Do not terminate mmdbresolve process on exit. Instead rely on process exit when EOF is received on standard input. Previously the EOF was never received because mmdbresolve inherited both ends of standard input pipe, i.e. the fact that Wireshark closed the write end was not observed by mmdbresolve because mmdbresolve kept write handle the standard input pipe open.
2022-08-15 08:51:20 +00:00
if (win32_create_process(NULL, command_line, NULL, NULL, G_N_ELEMENTS(inherit_handles), inherit_handles,
CREATE_NEW_CONSOLE, NULL, working_directory, &info, &processInfo))
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
{
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
gchar* stdout_buffer = (gchar*)g_malloc(BUFFER_SIZE);
gchar* stderr_buffer = (gchar*)g_malloc(BUFFER_SIZE);
Fix extcap initialization deadlock On Windows the code calling extcap worked as follows: 1. Create stdout and stderr pipes with default buffer size 2. Execute extcap redirecting output to the pipes 3. Wait for extcap process to exit 4. Read the data from stdout pipe This resulted in deadlock when the extcap wrote more data than the pipe could buffer. This was especially seen with USBPcap as it is quite normal to have plenty of USB devices connected. Fix the issue by contantly reading the stdout data and storing it in GString. To prevent similar deadlock on the stderr, the stderr data is being constantly monitored as well (and discarded). Change-Id: I0f93e6d79617cef0e828aef2b96fad2757227923 Bug: 14657 Reviewed-on: https://code.wireshark.org/review/29159 Petri-Dish: Pascal Quantin <pascal.quantin@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Roland Knall <rknall@gmail.com>
2018-08-16 16:04:07 +00:00
DWORD dw;
DWORD bytes_read;
GString *output_string = g_string_new(NULL);
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
gboolean process_finished = FALSE;
gboolean pending_stdout = TRUE;
gboolean pending_stderr = TRUE;
/* Start asynchronous reads from child process stdout and stderr */
if (!ReadFile(child_stdout_rd, stdout_buffer, BUFFER_SIZE, NULL, &stdout_overlapped))
{
if (GetLastError() != ERROR_IO_PENDING)
{
MinGW: Fix -Wformat
2023-01-12 03:43:59 +00:00
ws_debug("ReadFile on child stdout pipe failed. Error %ld", GetLastError());
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
pending_stdout = FALSE;
}
}
if (!ReadFile(child_stderr_rd, stderr_buffer, BUFFER_SIZE, NULL, &stderr_overlapped))
{
if (GetLastError() != ERROR_IO_PENDING)
{
MinGW: Fix -Wformat
2023-01-12 03:43:59 +00:00
ws_debug("ReadFile on child stderr pipe failed. Error %ld", GetLastError());
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
pending_stderr = FALSE;
}
}
Fix extcap initialization deadlock On Windows the code calling extcap worked as follows: 1. Create stdout and stderr pipes with default buffer size 2. Execute extcap redirecting output to the pipes 3. Wait for extcap process to exit 4. Read the data from stdout pipe This resulted in deadlock when the extcap wrote more data than the pipe could buffer. This was especially seen with USBPcap as it is quite normal to have plenty of USB devices connected. Fix the issue by contantly reading the stdout data and storing it in GString. To prevent similar deadlock on the stderr, the stderr data is being constantly monitored as well (and discarded). Change-Id: I0f93e6d79617cef0e828aef2b96fad2757227923 Bug: 14657 Reviewed-on: https://code.wireshark.org/review/29159 Petri-Dish: Pascal Quantin <pascal.quantin@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Roland Knall <rknall@gmail.com>
2018-08-16 16:04:07 +00:00
for (;;)
{
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
HANDLE handles[3];
DWORD n_handles = 0;
if (!process_finished)
Fix extcap initialization deadlock On Windows the code calling extcap worked as follows: 1. Create stdout and stderr pipes with default buffer size 2. Execute extcap redirecting output to the pipes 3. Wait for extcap process to exit 4. Read the data from stdout pipe This resulted in deadlock when the extcap wrote more data than the pipe could buffer. This was especially seen with USBPcap as it is quite normal to have plenty of USB devices connected. Fix the issue by contantly reading the stdout data and storing it in GString. To prevent similar deadlock on the stderr, the stderr data is being constantly monitored as well (and discarded). Change-Id: I0f93e6d79617cef0e828aef2b96fad2757227923 Bug: 14657 Reviewed-on: https://code.wireshark.org/review/29159 Petri-Dish: Pascal Quantin <pascal.quantin@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Roland Knall <rknall@gmail.com>
2018-08-16 16:04:07 +00:00
{
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
handles[n_handles++] = processInfo.hProcess;
}
if (pending_stdout)
{
handles[n_handles++] = stdout_overlapped.hEvent;
Do not pass pipe handle to WaitForMultipleObjects The Remarks section in WaitForMultipleObjects describes what kind of handles the function can wait for. Pipe handles are not listed there. The problem was introduced in c18459e66e8e71a8765bb9b8e2b3d2ba61855a3f While it might be possible to setup overlapped reads on the pipe handles and then wait on overlapped events, it would result in quite complex code. As a tradeoff, simply keep peeking at the pipes every 100 ms. Change-Id: I6ba4f4bf4c1d2af856027cca36ffd6d4f7f49f36 Bug: 14657 Reviewed-on: https://code.wireshark.org/review/29163 Petri-Dish: Roland Knall <rknall@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Roland Knall <rknall@gmail.com>
2018-08-16 19:06:41 +00:00
}
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
if (pending_stderr)
Do not pass pipe handle to WaitForMultipleObjects The Remarks section in WaitForMultipleObjects describes what kind of handles the function can wait for. Pipe handles are not listed there. The problem was introduced in c18459e66e8e71a8765bb9b8e2b3d2ba61855a3f While it might be possible to setup overlapped reads on the pipe handles and then wait on overlapped events, it would result in quite complex code. As a tradeoff, simply keep peeking at the pipes every 100 ms. Change-Id: I6ba4f4bf4c1d2af856027cca36ffd6d4f7f49f36 Bug: 14657 Reviewed-on: https://code.wireshark.org/review/29163 Petri-Dish: Roland Knall <rknall@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Roland Knall <rknall@gmail.com>
2018-08-16 19:06:41 +00:00
{
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
handles[n_handles++] = stderr_overlapped.hEvent;
}
if (!n_handles)
{
/* No more things to wait */
Do not pass pipe handle to WaitForMultipleObjects The Remarks section in WaitForMultipleObjects describes what kind of handles the function can wait for. Pipe handles are not listed there. The problem was introduced in c18459e66e8e71a8765bb9b8e2b3d2ba61855a3f While it might be possible to setup overlapped reads on the pipe handles and then wait on overlapped events, it would result in quite complex code. As a tradeoff, simply keep peeking at the pipes every 100 ms. Change-Id: I6ba4f4bf4c1d2af856027cca36ffd6d4f7f49f36 Bug: 14657 Reviewed-on: https://code.wireshark.org/review/29163 Petri-Dish: Roland Knall <rknall@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Roland Knall <rknall@gmail.com>
2018-08-16 19:06:41 +00:00
break;
}
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
dw = WaitForMultipleObjects(n_handles, handles, FALSE, INFINITE);
if (dw < (WAIT_OBJECT_0 + n_handles))
Do not pass pipe handle to WaitForMultipleObjects The Remarks section in WaitForMultipleObjects describes what kind of handles the function can wait for. Pipe handles are not listed there. The problem was introduced in c18459e66e8e71a8765bb9b8e2b3d2ba61855a3f While it might be possible to setup overlapped reads on the pipe handles and then wait on overlapped events, it would result in quite complex code. As a tradeoff, simply keep peeking at the pipes every 100 ms. Change-Id: I6ba4f4bf4c1d2af856027cca36ffd6d4f7f49f36 Bug: 14657 Reviewed-on: https://code.wireshark.org/review/29163 Petri-Dish: Roland Knall <rknall@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Roland Knall <rknall@gmail.com>
2018-08-16 19:06:41 +00:00
{
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
int i = dw - WAIT_OBJECT_0;
if (handles[i] == processInfo.hProcess)
{
/* Process finished but there might still be unread data in the pipe.
* Close the write pipes, so ReadFile does not wait indefinitely.
*/
CloseHandle(child_stdout_wr);
CloseHandle(child_stderr_wr);
process_finished = TRUE;
}
else if (handles[i] == stdout_overlapped.hEvent)
Fix extcap initialization deadlock On Windows the code calling extcap worked as follows: 1. Create stdout and stderr pipes with default buffer size 2. Execute extcap redirecting output to the pipes 3. Wait for extcap process to exit 4. Read the data from stdout pipe This resulted in deadlock when the extcap wrote more data than the pipe could buffer. This was especially seen with USBPcap as it is quite normal to have plenty of USB devices connected. Fix the issue by contantly reading the stdout data and storing it in GString. To prevent similar deadlock on the stderr, the stderr data is being constantly monitored as well (and discarded). Change-Id: I0f93e6d79617cef0e828aef2b96fad2757227923 Bug: 14657 Reviewed-on: https://code.wireshark.org/review/29159 Petri-Dish: Pascal Quantin <pascal.quantin@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Roland Knall <rknall@gmail.com>
2018-08-16 16:04:07 +00:00
{
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
bytes_read = 0;
if (!GetOverlappedResult(child_stdout_rd, &stdout_overlapped, &bytes_read, TRUE))
{
if (GetLastError() == ERROR_BROKEN_PIPE)
{
pending_stdout = FALSE;
continue;
}
MinGW: Fix -Wformat
2023-01-12 03:43:59 +00:00
ws_debug("GetOverlappedResult on stdout failed. Error %ld", GetLastError());
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
}
if (process_finished && (bytes_read == 0))
{
/* We have drained the pipe and there isn't any process that holds active write handle to the pipe. */
pending_stdout = FALSE;
continue;
}
g_string_append_len(output_string, stdout_buffer, bytes_read);
if (!ReadFile(child_stdout_rd, stdout_buffer, BUFFER_SIZE, NULL, &stdout_overlapped))
Fix extcap initialization deadlock On Windows the code calling extcap worked as follows: 1. Create stdout and stderr pipes with default buffer size 2. Execute extcap redirecting output to the pipes 3. Wait for extcap process to exit 4. Read the data from stdout pipe This resulted in deadlock when the extcap wrote more data than the pipe could buffer. This was especially seen with USBPcap as it is quite normal to have plenty of USB devices connected. Fix the issue by contantly reading the stdout data and storing it in GString. To prevent similar deadlock on the stderr, the stderr data is being constantly monitored as well (and discarded). Change-Id: I0f93e6d79617cef0e828aef2b96fad2757227923 Bug: 14657 Reviewed-on: https://code.wireshark.org/review/29159 Petri-Dish: Pascal Quantin <pascal.quantin@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Roland Knall <rknall@gmail.com>
2018-08-16 16:04:07 +00:00
{
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
if (GetLastError() != ERROR_IO_PENDING)
{
MinGW: Fix -Wformat
2023-01-12 03:43:59 +00:00
ws_debug("ReadFile on child stdout pipe failed. Error %ld", GetLastError());
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
pending_stdout = FALSE;
}
Fix extcap initialization deadlock On Windows the code calling extcap worked as follows: 1. Create stdout and stderr pipes with default buffer size 2. Execute extcap redirecting output to the pipes 3. Wait for extcap process to exit 4. Read the data from stdout pipe This resulted in deadlock when the extcap wrote more data than the pipe could buffer. This was especially seen with USBPcap as it is quite normal to have plenty of USB devices connected. Fix the issue by contantly reading the stdout data and storing it in GString. To prevent similar deadlock on the stderr, the stderr data is being constantly monitored as well (and discarded). Change-Id: I0f93e6d79617cef0e828aef2b96fad2757227923 Bug: 14657 Reviewed-on: https://code.wireshark.org/review/29159 Petri-Dish: Pascal Quantin <pascal.quantin@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Roland Knall <rknall@gmail.com>
2018-08-16 16:04:07 +00:00
}
}
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
else if (handles[i] == stderr_overlapped.hEvent)
Do not pass pipe handle to WaitForMultipleObjects The Remarks section in WaitForMultipleObjects describes what kind of handles the function can wait for. Pipe handles are not listed there. The problem was introduced in c18459e66e8e71a8765bb9b8e2b3d2ba61855a3f While it might be possible to setup overlapped reads on the pipe handles and then wait on overlapped events, it would result in quite complex code. As a tradeoff, simply keep peeking at the pipes every 100 ms. Change-Id: I6ba4f4bf4c1d2af856027cca36ffd6d4f7f49f36 Bug: 14657 Reviewed-on: https://code.wireshark.org/review/29163 Petri-Dish: Roland Knall <rknall@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Roland Knall <rknall@gmail.com>
2018-08-16 19:06:41 +00:00
{
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
/* Discard the stderr data just like non-windows version of this function does. */
bytes_read = 0;
if (!GetOverlappedResult(child_stderr_rd, &stderr_overlapped, &bytes_read, TRUE))
{
if (GetLastError() == ERROR_BROKEN_PIPE)
{
pending_stderr = FALSE;
continue;
}
MinGW: Fix -Wformat
2023-01-12 03:43:59 +00:00
ws_debug("GetOverlappedResult on stderr failed. Error %ld", GetLastError());
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
}
if (process_finished && (bytes_read == 0))
{
pending_stderr = FALSE;
continue;
}
if (!ReadFile(child_stderr_rd, stderr_buffer, BUFFER_SIZE, NULL, &stderr_overlapped))
{
if (GetLastError() != ERROR_IO_PENDING)
{
MinGW: Fix -Wformat
2023-01-12 03:43:59 +00:00
ws_debug("ReadFile on child stderr pipe failed. Error %ld", GetLastError());
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
pending_stderr = FALSE;
}
}
Do not pass pipe handle to WaitForMultipleObjects The Remarks section in WaitForMultipleObjects describes what kind of handles the function can wait for. Pipe handles are not listed there. The problem was introduced in c18459e66e8e71a8765bb9b8e2b3d2ba61855a3f While it might be possible to setup overlapped reads on the pipe handles and then wait on overlapped events, it would result in quite complex code. As a tradeoff, simply keep peeking at the pipes every 100 ms. Change-Id: I6ba4f4bf4c1d2af856027cca36ffd6d4f7f49f36 Bug: 14657 Reviewed-on: https://code.wireshark.org/review/29163 Petri-Dish: Roland Knall <rknall@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Roland Knall <rknall@gmail.com>
2018-08-16 19:06:41 +00:00
}
Fix extcap initialization deadlock On Windows the code calling extcap worked as follows: 1. Create stdout and stderr pipes with default buffer size 2. Execute extcap redirecting output to the pipes 3. Wait for extcap process to exit 4. Read the data from stdout pipe This resulted in deadlock when the extcap wrote more data than the pipe could buffer. This was especially seen with USBPcap as it is quite normal to have plenty of USB devices connected. Fix the issue by contantly reading the stdout data and storing it in GString. To prevent similar deadlock on the stderr, the stderr data is being constantly monitored as well (and discarded). Change-Id: I0f93e6d79617cef0e828aef2b96fad2757227923 Bug: 14657 Reviewed-on: https://code.wireshark.org/review/29159 Petri-Dish: Pascal Quantin <pascal.quantin@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Roland Knall <rknall@gmail.com>
2018-08-16 16:04:07 +00:00
}
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
else
Fix extcap initialization deadlock On Windows the code calling extcap worked as follows: 1. Create stdout and stderr pipes with default buffer size 2. Execute extcap redirecting output to the pipes 3. Wait for extcap process to exit 4. Read the data from stdout pipe This resulted in deadlock when the extcap wrote more data than the pipe could buffer. This was especially seen with USBPcap as it is quite normal to have plenty of USB devices connected. Fix the issue by contantly reading the stdout data and storing it in GString. To prevent similar deadlock on the stderr, the stderr data is being constantly monitored as well (and discarded). Change-Id: I0f93e6d79617cef0e828aef2b96fad2757227923 Bug: 14657 Reviewed-on: https://code.wireshark.org/review/29159 Petri-Dish: Pascal Quantin <pascal.quantin@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Roland Knall <rknall@gmail.com>
2018-08-16 16:04:07 +00:00
{
MinGW: Fix -Wformat
2023-01-12 03:43:59 +00:00
ws_debug("WaitForMultipleObjects returned 0x%08lX. Error %ld", dw, GetLastError());
Fix extcap initialization deadlock On Windows the code calling extcap worked as follows: 1. Create stdout and stderr pipes with default buffer size 2. Execute extcap redirecting output to the pipes 3. Wait for extcap process to exit 4. Read the data from stdout pipe This resulted in deadlock when the extcap wrote more data than the pipe could buffer. This was especially seen with USBPcap as it is quite normal to have plenty of USB devices connected. Fix the issue by contantly reading the stdout data and storing it in GString. To prevent similar deadlock on the stderr, the stderr data is being constantly monitored as well (and discarded). Change-Id: I0f93e6d79617cef0e828aef2b96fad2757227923 Bug: 14657 Reviewed-on: https://code.wireshark.org/review/29159 Petri-Dish: Pascal Quantin <pascal.quantin@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Roland Knall <rknall@gmail.com>
2018-08-16 16:04:07 +00:00
}
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
}
Fix extcap initialization deadlock On Windows the code calling extcap worked as follows: 1. Create stdout and stderr pipes with default buffer size 2. Execute extcap redirecting output to the pipes 3. Wait for extcap process to exit 4. Read the data from stdout pipe This resulted in deadlock when the extcap wrote more data than the pipe could buffer. This was especially seen with USBPcap as it is quite normal to have plenty of USB devices connected. Fix the issue by contantly reading the stdout data and storing it in GString. To prevent similar deadlock on the stderr, the stderr data is being constantly monitored as well (and discarded). Change-Id: I0f93e6d79617cef0e828aef2b96fad2757227923 Bug: 14657 Reviewed-on: https://code.wireshark.org/review/29159 Petri-Dish: Pascal Quantin <pascal.quantin@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Roland Knall <rknall@gmail.com>
2018-08-16 16:04:07 +00:00
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
g_free(stdout_buffer);
g_free(stderr_buffer);
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
Fix extcap initialization deadlock On Windows the code calling extcap worked as follows: 1. Create stdout and stderr pipes with default buffer size 2. Execute extcap redirecting output to the pipes 3. Wait for extcap process to exit 4. Read the data from stdout pipe This resulted in deadlock when the extcap wrote more data than the pipe could buffer. This was especially seen with USBPcap as it is quite normal to have plenty of USB devices connected. Fix the issue by contantly reading the stdout data and storing it in GString. To prevent similar deadlock on the stderr, the stderr data is being constantly monitored as well (and discarded). Change-Id: I0f93e6d79617cef0e828aef2b96fad2757227923 Bug: 14657 Reviewed-on: https://code.wireshark.org/review/29159 Petri-Dish: Pascal Quantin <pascal.quantin@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Roland Knall <rknall@gmail.com>
2018-08-16 16:04:07 +00:00
status = GetExitCodeProcess(processInfo.hProcess, &dw);
if (status && dw != 0)
{
status = FALSE;
}
local_output = g_string_free(output_string, FALSE);
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
CloseHandle(child_stdout_rd);
CloseHandle(child_stderr_rd);
CloseHandle(processInfo.hProcess);
CloseHandle(processInfo.hThread);
}
else
wsutil: Fix pipe handle leaks on Windows If the PATHEXT environment variable contains .py and extcap is enabled, then Wireshark did leak 2 pipes for every .py file present in the extcap directory (regardless if there was .bat wrapper for it or not). Bug: 15689 Change-Id: Iae402c0075ee8155a7205a59711bbae734da7e9e Reviewed-on: https://code.wireshark.org/review/32812 Tested-by: Petri Dish Buildbot Reviewed-by: Guy Harris <guy@alum.mit.edu>
2019-04-10 16:19:18 +00:00
{
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
status = FALSE;
wsutil: Fix pipe handle leaks on Windows If the PATHEXT environment variable contains .py and extcap is enabled, then Wireshark did leak 2 pipes for every .py file present in the extcap directory (regardless if there was .bat wrapper for it or not). Bug: 15689 Change-Id: Iae402c0075ee8155a7205a59711bbae734da7e9e Reviewed-on: https://code.wireshark.org/review/32812 Tested-by: Petri Dish Buildbot Reviewed-by: Guy Harris <guy@alum.mit.edu>
2019-04-10 16:19:18 +00:00
CloseHandle(child_stdout_rd);
CloseHandle(child_stdout_wr);
CloseHandle(child_stderr_rd);
CloseHandle(child_stderr_wr);
}
wsutil: Read stderr and stdout data asynchronously This significantly reduces the initialization time when system is using small pipe buffers. No time is lost on periodic process status checks as WaitForMultipleObjects() returns when the stdout/stderr data was read and/or when process finishes. Bug: 14657 Change-Id: I61fabf986577db7102a3136df83d2d92c7156727 Reviewed-on: https://code.wireshark.org/review/32773 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-11 14:45:21 +00:00
CloseHandle(stdout_overlapped.hEvent);
CloseHandle(stderr_overlapped.hEvent);
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
#else
ws_pipe_spawn_*: fix deadlock in g_spawn on Linux with threads The deadlock can be observed with a slow malloc implementation, e.g. ASAN_OPTIONS=fast_unwind_on_malloc=0 tshark --version (This calls extcap_run_all which uses threads and ws_pipe_spawn_sync.) Change-Id: Iff329c465c53ed177980368cd645f59222f88dd3 Reviewed-on: https://code.wireshark.org/review/30777 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-11-24 14:20:22 +00:00
GSpawnFlags flags = (GSpawnFlags)0;
GSpawnChildSetupFunc child_setup = NULL;
#ifdef HAS_G_SPAWN_LINUX_THREAD_SAFETY_BUG
flags = (GSpawnFlags)(flags | G_SPAWN_LEAVE_DESCRIPTORS_OPEN);
child_setup = close_non_standard_fds_linux;
#endif
ws_pipe_spawn_sync: mark arguments as const where possible This avoids an unnecessary explicit cast. For clarity, rename the working directory argument to match g_spawn_sync. Change-Id: Idf7072cd590e686294d953f77da2a52c861a89c0 Reviewed-on: https://code.wireshark.org/review/30763 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-11-22 15:45:41 +00:00
status = g_spawn_sync(working_directory, argv, NULL,
ws_pipe_spawn_*: fix deadlock in g_spawn on Linux with threads The deadlock can be observed with a slow malloc implementation, e.g. ASAN_OPTIONS=fast_unwind_on_malloc=0 tshark --version (This calls extcap_run_all which uses threads and ws_pipe_spawn_sync.) Change-Id: Iff329c465c53ed177980368cd645f59222f88dd3 Reviewed-on: https://code.wireshark.org/review/30777 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-11-24 14:20:22 +00:00
flags, child_setup, NULL, &local_output, NULL, &exit_status, NULL);
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
if (status && exit_status != 0)
status = FALSE;
#endif
Refactor our logging and extend the wslog API Experience has shown that: 1. The current logging methods are not very reliable or practical. A logging bitmask makes little sense as the user-facing interface (who would want debug but not crtical messages for example?); it's computer-friendly and user-unfriendly. More importantly the console log level preference is initialized too late in the startup process to be used for the logging subsystem and that fact raises a number of annoying and hard-to-fix usability issues. 2. Coding around G_MESSAGES_DEBUG to comply with our log level mask and not clobber the user's settings or not create unexpected log misses is unworkable and generally follows the principle of most surprise. The fact that G_MESSAGES_DEBUG="all" can leak to other programs using GLib is also annoying. 3. The non-structured GLib logging API is very opinionated and lacks configurability beyond replacing the log handler. 4. Windows GUI has some special code to attach to a console, but it would be nice to abstract away the rest under a single interface. 5. Using this logger seems to be noticeably faster. Deprecate the console log level preference and extend our API to implement a log handler in wsutil/wslog.h to provide easy-to-use, flexible and dependable logging during all execution phases. Log levels have a hierarchy, from most verbose to least verbose (debug to error). When a given level is set everything above that is also enabled. The log level can be set with an environment variable or a command line option (parsed as soon as possible but still later than the environment). The default log level is "message". Dissector logging is not included because it is not clear what log domain they should use. An explosion to thousands of domains is not desirable and putting everything in a single domain is probably too coarse and noisy. For now I think it makes sense to let them do their own thing using g_log_default_handler() and continue using the G_MESSAGES_DEBUG mechanism with specific domains for each individual dissector. In the future a mechanism may be added to selectively enable these domains at runtime while trying to avoid the problems introduced by G_MESSAGES_DEBUG.
2021-06-08 01:46:52 +00:00
ws_debug("%s finished in %.3fms", argv[0], (g_get_monotonic_time() - start_time) / 1000.0);
ws_pipe_spawn_sync: debug log elapsed time Tested with `G_MESSAGES_DEBUG=all tshark --version`. Change-Id: Iae525b9de197f012c21693a91155f931d4dcc1f7 Ping-Bug: 15295 Reviewed-on: https://code.wireshark.org/review/30759 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-11-22 10:29:03 +00:00
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
if (status)
{
Allow trace of sync spawns When Wireshark uses a synchronous spawn (e.g., to launch an extcap) it would be nice to be able to see what command line is constructed to launch the process, and to see what comes back. The output will go to the g_log. Change-Id: Iec6baeebc026cd80398084c9644fc916ab068e2f Reviewed-on: https://code.wireshark.org/review/30475 Petri-Dish: Dario Lombardo <lomato@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Peter Wu <peter@lekensteyn.nl>
2018-11-01 16:20:47 +00:00
if (local_output != NULL) {
Debug: Lower priority to "noisy" for pipe spawn output Spawn output can include very long multiline extcap arguments.
2021-06-23 17:17:40 +00:00
ws_noisy("spawn output: %s", local_output);
Allow trace of sync spawns When Wireshark uses a synchronous spawn (e.g., to launch an extcap) it would be nice to be able to see what command line is constructed to launch the process, and to see what comes back. The output will go to the g_log. Change-Id: Iec6baeebc026cd80398084c9644fc916ab068e2f Reviewed-on: https://code.wireshark.org/review/30475 Petri-Dish: Dario Lombardo <lomato@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Peter Wu <peter@lekensteyn.nl>
2018-11-01 16:20:47 +00:00
if (command_output != NULL)
*command_output = g_strdup(local_output);
}
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
result = TRUE;
}
g_free(local_output);
ws_pipe: fix memory leaks in spawn arguments handling On Windows, ws_pipe_spawn_sync always leaks 'winargs', and leaks 'argv' on some error paths. Fix these and refactor the common argument parsing functionality to reduce duplication of functionality. Change-Id: I8fa5ca45aec20b53f6fa243b0dd07241a345f7ab Reviewed-on: https://code.wireshark.org/review/32932 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Peter Wu <peter@lekensteyn.nl>
2019-04-21 18:48:11 +00:00
g_free(command_line);
g_strfreev(argv);
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
return result;
}
More spawned process handling updates. Document ws_pipe.h. Define invalid PIDs in one place. Extcap didn't use stdin before 1a0987904f. Make sure we close it. Change-Id: I7a69cd9b5137ae82435e64628a22e4d812d58f89 Reviewed-on: https://code.wireshark.org/review/26226 Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Gerald Combs <gerald@wireshark.org>
2018-03-02 17:11:31 +00:00
void ws_pipe_init(ws_pipe_t *ws_pipe)
{
if (!ws_pipe) return;
memset(ws_pipe, 0, sizeof(ws_pipe_t));
ws_pipe->pid = WS_INVALID_PID;
}
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
GPid ws_pipe_spawn_async(ws_pipe_t *ws_pipe, GPtrArray *args)
{
More spawned process handling updates. Document ws_pipe.h. Define invalid PIDs in one place. Extcap didn't use stdin before 1a0987904f. Make sure we close it. Change-Id: I7a69cd9b5137ae82435e64628a22e4d812d58f89 Reviewed-on: https://code.wireshark.org/review/26226 Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Gerald Combs <gerald@wireshark.org>
2018-03-02 17:11:31 +00:00
GPid pid = WS_INVALID_PID;
wsutil: Use GIOChannel for standard pipes Remove ws_read_string_from_pipe() as this function encourages bad design and is no longer necessary. Extcap stderr is read only after the child process has finished and thus the read will never block. Close process information thread handle right away as we don't use it. Remove unused ws_pipe_t member variables.
2022-08-07 14:12:24 +00:00
gint stdin_fd, stdout_fd, stderr_fd;
Allow trace of sync spawns When Wireshark uses a synchronous spawn (e.g., to launch an extcap) it would be nice to be able to see what command line is constructed to launch the process, and to see what comes back. The output will go to the g_log. Change-Id: Iec6baeebc026cd80398084c9644fc916ab068e2f Reviewed-on: https://code.wireshark.org/review/30475 Petri-Dish: Dario Lombardo <lomato@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Peter Wu <peter@lekensteyn.nl>
2018-11-01 16:20:47 +00:00
#ifdef _WIN32
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
STARTUPINFO info;
PROCESS_INFORMATION processInfo;
SECURITY_ATTRIBUTES sa;
HANDLE child_stdin_rd = NULL;
HANDLE child_stdin_wr = NULL;
HANDLE child_stdout_rd = NULL;
HANDLE child_stdout_wr = NULL;
HANDLE child_stderr_rd = NULL;
HANDLE child_stderr_wr = NULL;
win32-utils: Explicitly list inherited handles Windows processes inherit all inheritable handles when a new process is created using CreateProcess() with bInheritHandles set to TRUE. This can lead to undesired object lifetime extension. That is, the child process will keep ineritable handles alive even if it does not use them. Up to Windows Vista it was not possible explicitly list handles that should be inherited. Wireshark no longer works on Windows releases earlier than Vista, so use the new API without checking Windows version. Require all callers to win32_create_process() to pass in the list of handles to inherit. Set the listed handles as inheritable shortly before calling CreateProcess() and set them as not inheritable shortly after the process is created. This minimizes possibility for other callers (especially in 3rd party libraries) to inherit handles by accident. Do not terminate mmdbresolve process on exit. Instead rely on process exit when EOF is received on standard input. Previously the EOF was never received because mmdbresolve inherited both ends of standard input pipe, i.e. the fact that Wireshark closed the write end was not observed by mmdbresolve because mmdbresolve kept write handle the standard input pipe open.
2022-08-15 08:51:20 +00:00
HANDLE inherit_handles[3];
ws_pipe: fix memory leaks in spawn arguments handling On Windows, ws_pipe_spawn_sync always leaks 'winargs', and leaks 'argv' on some error paths. Fix these and refactor the common argument parsing functionality to reduce duplication of functionality. Change-Id: I8fa5ca45aec20b53f6fa243b0dd07241a345f7ab Reviewed-on: https://code.wireshark.org/review/32932 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Peter Wu <peter@lekensteyn.nl>
2019-04-21 18:48:11 +00:00
#endif
// XXX harmonize handling of command arguments for the sync/async functions
// and make them const? This array ends with a trailing NULL by the way.
gchar **args_array = (gchar **)args->pdata;
gchar **argv = convert_to_argv(args_array[0], args->len - 2, args_array + 1);
gchar *command_line = convert_to_command_line(argv);
Refactor our logging and extend the wslog API Experience has shown that: 1. The current logging methods are not very reliable or practical. A logging bitmask makes little sense as the user-facing interface (who would want debug but not crtical messages for example?); it's computer-friendly and user-unfriendly. More importantly the console log level preference is initialized too late in the startup process to be used for the logging subsystem and that fact raises a number of annoying and hard-to-fix usability issues. 2. Coding around G_MESSAGES_DEBUG to comply with our log level mask and not clobber the user's settings or not create unexpected log misses is unworkable and generally follows the principle of most surprise. The fact that G_MESSAGES_DEBUG="all" can leak to other programs using GLib is also annoying. 3. The non-structured GLib logging API is very opinionated and lacks configurability beyond replacing the log handler. 4. Windows GUI has some special code to attach to a console, but it would be nice to abstract away the rest under a single interface. 5. Using this logger seems to be noticeably faster. Deprecate the console log level preference and extend our API to implement a log handler in wsutil/wslog.h to provide easy-to-use, flexible and dependable logging during all execution phases. Log levels have a hierarchy, from most verbose to least verbose (debug to error). When a given level is set everything above that is also enabled. The log level can be set with an environment variable or a command line option (parsed as soon as possible but still later than the environment). The default log level is "message". Dissector logging is not included because it is not clear what log domain they should use. An explosion to thousands of domains is not desirable and putting everything in a single domain is probably too coarse and noisy. For now I think it makes sense to let them do their own thing using g_log_default_handler() and continue using the G_MESSAGES_DEBUG mechanism with specific domains for each individual dissector. In the future a mechanism may be added to selectively enable these domains at runtime while trying to avoid the problems introduced by G_MESSAGES_DEBUG.
2021-06-08 01:46:52 +00:00
ws_debug("command line: %s", command_line);
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
ws_pipe: fix memory leaks in spawn arguments handling On Windows, ws_pipe_spawn_sync always leaks 'winargs', and leaks 'argv' on some error paths. Fix these and refactor the common argument parsing functionality to reduce duplication of functionality. Change-Id: I8fa5ca45aec20b53f6fa243b0dd07241a345f7ab Reviewed-on: https://code.wireshark.org/review/32932 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Peter Wu <peter@lekensteyn.nl>
2019-04-21 18:48:11 +00:00
#ifdef _WIN32
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
sa.nLength = sizeof(SECURITY_ATTRIBUTES);
win32-utils: Explicitly list inherited handles Windows processes inherit all inheritable handles when a new process is created using CreateProcess() with bInheritHandles set to TRUE. This can lead to undesired object lifetime extension. That is, the child process will keep ineritable handles alive even if it does not use them. Up to Windows Vista it was not possible explicitly list handles that should be inherited. Wireshark no longer works on Windows releases earlier than Vista, so use the new API without checking Windows version. Require all callers to win32_create_process() to pass in the list of handles to inherit. Set the listed handles as inheritable shortly before calling CreateProcess() and set them as not inheritable shortly after the process is created. This minimizes possibility for other callers (especially in 3rd party libraries) to inherit handles by accident. Do not terminate mmdbresolve process on exit. Instead rely on process exit when EOF is received on standard input. Previously the EOF was never received because mmdbresolve inherited both ends of standard input pipe, i.e. the fact that Wireshark closed the write end was not observed by mmdbresolve because mmdbresolve kept write handle the standard input pipe open.
2022-08-15 08:51:20 +00:00
sa.bInheritHandle = FALSE;
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
sa.lpSecurityDescriptor = NULL;
if (!CreatePipe(&child_stdin_rd, &child_stdin_wr, &sa, 0))
{
ws_pipe: fix memory leaks in spawn arguments handling On Windows, ws_pipe_spawn_sync always leaks 'winargs', and leaks 'argv' on some error paths. Fix these and refactor the common argument parsing functionality to reduce duplication of functionality. Change-Id: I8fa5ca45aec20b53f6fa243b0dd07241a345f7ab Reviewed-on: https://code.wireshark.org/review/32932 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Peter Wu <peter@lekensteyn.nl>
2019-04-21 18:48:11 +00:00
g_free(command_line);
g_strfreev(argv);
Refactor our logging and extend the wslog API Experience has shown that: 1. The current logging methods are not very reliable or practical. A logging bitmask makes little sense as the user-facing interface (who would want debug but not crtical messages for example?); it's computer-friendly and user-unfriendly. More importantly the console log level preference is initialized too late in the startup process to be used for the logging subsystem and that fact raises a number of annoying and hard-to-fix usability issues. 2. Coding around G_MESSAGES_DEBUG to comply with our log level mask and not clobber the user's settings or not create unexpected log misses is unworkable and generally follows the principle of most surprise. The fact that G_MESSAGES_DEBUG="all" can leak to other programs using GLib is also annoying. 3. The non-structured GLib logging API is very opinionated and lacks configurability beyond replacing the log handler. 4. Windows GUI has some special code to attach to a console, but it would be nice to abstract away the rest under a single interface. 5. Using this logger seems to be noticeably faster. Deprecate the console log level preference and extend our API to implement a log handler in wsutil/wslog.h to provide easy-to-use, flexible and dependable logging during all execution phases. Log levels have a hierarchy, from most verbose to least verbose (debug to error). When a given level is set everything above that is also enabled. The log level can be set with an environment variable or a command line option (parsed as soon as possible but still later than the environment). The default log level is "message". Dissector logging is not included because it is not clear what log domain they should use. An explosion to thousands of domains is not desirable and putting everything in a single domain is probably too coarse and noisy. For now I think it makes sense to let them do their own thing using g_log_default_handler() and continue using the G_MESSAGES_DEBUG mechanism with specific domains for each individual dissector. In the future a mechanism may be added to selectively enable these domains at runtime while trying to avoid the problems introduced by G_MESSAGES_DEBUG.
2021-06-08 01:46:52 +00:00
ws_debug("Could not create stdin handle");
ws_pipe: fix return value of ws_pipe_spawn_async on error path The function returns a GPid, not a gboolean. Callers (mmdbresolv and extcap) only assume WS_INVALID_PID to be invalid (as documented). Change-Id: I40b491272a451f569864fa3259009d6d3fcce772 Fixes: v2.5.1rc0-413-g1a0987904f ("Generalize our process spawning code.") Reviewed-on: https://code.wireshark.org/review/32933 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-21 20:17:45 +00:00
return WS_INVALID_PID;
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
}
if (!CreatePipe(&child_stdout_rd, &child_stdout_wr, &sa, 0))
{
wsutil: Fix pipe handle leaks on Windows If the PATHEXT environment variable contains .py and extcap is enabled, then Wireshark did leak 2 pipes for every .py file present in the extcap directory (regardless if there was .bat wrapper for it or not). Bug: 15689 Change-Id: Iae402c0075ee8155a7205a59711bbae734da7e9e Reviewed-on: https://code.wireshark.org/review/32812 Tested-by: Petri Dish Buildbot Reviewed-by: Guy Harris <guy@alum.mit.edu>
2019-04-10 16:19:18 +00:00
CloseHandle(child_stdin_rd);
CloseHandle(child_stdin_wr);
ws_pipe: fix memory leaks in spawn arguments handling On Windows, ws_pipe_spawn_sync always leaks 'winargs', and leaks 'argv' on some error paths. Fix these and refactor the common argument parsing functionality to reduce duplication of functionality. Change-Id: I8fa5ca45aec20b53f6fa243b0dd07241a345f7ab Reviewed-on: https://code.wireshark.org/review/32932 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Peter Wu <peter@lekensteyn.nl>
2019-04-21 18:48:11 +00:00
g_free(command_line);
g_strfreev(argv);
Refactor our logging and extend the wslog API Experience has shown that: 1. The current logging methods are not very reliable or practical. A logging bitmask makes little sense as the user-facing interface (who would want debug but not crtical messages for example?); it's computer-friendly and user-unfriendly. More importantly the console log level preference is initialized too late in the startup process to be used for the logging subsystem and that fact raises a number of annoying and hard-to-fix usability issues. 2. Coding around G_MESSAGES_DEBUG to comply with our log level mask and not clobber the user's settings or not create unexpected log misses is unworkable and generally follows the principle of most surprise. The fact that G_MESSAGES_DEBUG="all" can leak to other programs using GLib is also annoying. 3. The non-structured GLib logging API is very opinionated and lacks configurability beyond replacing the log handler. 4. Windows GUI has some special code to attach to a console, but it would be nice to abstract away the rest under a single interface. 5. Using this logger seems to be noticeably faster. Deprecate the console log level preference and extend our API to implement a log handler in wsutil/wslog.h to provide easy-to-use, flexible and dependable logging during all execution phases. Log levels have a hierarchy, from most verbose to least verbose (debug to error). When a given level is set everything above that is also enabled. The log level can be set with an environment variable or a command line option (parsed as soon as possible but still later than the environment). The default log level is "message". Dissector logging is not included because it is not clear what log domain they should use. An explosion to thousands of domains is not desirable and putting everything in a single domain is probably too coarse and noisy. For now I think it makes sense to let them do their own thing using g_log_default_handler() and continue using the G_MESSAGES_DEBUG mechanism with specific domains for each individual dissector. In the future a mechanism may be added to selectively enable these domains at runtime while trying to avoid the problems introduced by G_MESSAGES_DEBUG.
2021-06-08 01:46:52 +00:00
ws_debug("Could not create stdout handle");
ws_pipe: fix return value of ws_pipe_spawn_async on error path The function returns a GPid, not a gboolean. Callers (mmdbresolv and extcap) only assume WS_INVALID_PID to be invalid (as documented). Change-Id: I40b491272a451f569864fa3259009d6d3fcce772 Fixes: v2.5.1rc0-413-g1a0987904f ("Generalize our process spawning code.") Reviewed-on: https://code.wireshark.org/review/32933 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-21 20:17:45 +00:00
return WS_INVALID_PID;
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
}
if (!CreatePipe(&child_stderr_rd, &child_stderr_wr, &sa, 0))
{
wsutil: Fix pipe handle leaks on Windows If the PATHEXT environment variable contains .py and extcap is enabled, then Wireshark did leak 2 pipes for every .py file present in the extcap directory (regardless if there was .bat wrapper for it or not). Bug: 15689 Change-Id: Iae402c0075ee8155a7205a59711bbae734da7e9e Reviewed-on: https://code.wireshark.org/review/32812 Tested-by: Petri Dish Buildbot Reviewed-by: Guy Harris <guy@alum.mit.edu>
2019-04-10 16:19:18 +00:00
CloseHandle(child_stdin_rd);
CloseHandle(child_stdin_wr);
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
CloseHandle(child_stdout_rd);
CloseHandle(child_stdout_wr);
ws_pipe: fix memory leaks in spawn arguments handling On Windows, ws_pipe_spawn_sync always leaks 'winargs', and leaks 'argv' on some error paths. Fix these and refactor the common argument parsing functionality to reduce duplication of functionality. Change-Id: I8fa5ca45aec20b53f6fa243b0dd07241a345f7ab Reviewed-on: https://code.wireshark.org/review/32932 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Peter Wu <peter@lekensteyn.nl>
2019-04-21 18:48:11 +00:00
g_free(command_line);
g_strfreev(argv);
Refactor our logging and extend the wslog API Experience has shown that: 1. The current logging methods are not very reliable or practical. A logging bitmask makes little sense as the user-facing interface (who would want debug but not crtical messages for example?); it's computer-friendly and user-unfriendly. More importantly the console log level preference is initialized too late in the startup process to be used for the logging subsystem and that fact raises a number of annoying and hard-to-fix usability issues. 2. Coding around G_MESSAGES_DEBUG to comply with our log level mask and not clobber the user's settings or not create unexpected log misses is unworkable and generally follows the principle of most surprise. The fact that G_MESSAGES_DEBUG="all" can leak to other programs using GLib is also annoying. 3. The non-structured GLib logging API is very opinionated and lacks configurability beyond replacing the log handler. 4. Windows GUI has some special code to attach to a console, but it would be nice to abstract away the rest under a single interface. 5. Using this logger seems to be noticeably faster. Deprecate the console log level preference and extend our API to implement a log handler in wsutil/wslog.h to provide easy-to-use, flexible and dependable logging during all execution phases. Log levels have a hierarchy, from most verbose to least verbose (debug to error). When a given level is set everything above that is also enabled. The log level can be set with an environment variable or a command line option (parsed as soon as possible but still later than the environment). The default log level is "message". Dissector logging is not included because it is not clear what log domain they should use. An explosion to thousands of domains is not desirable and putting everything in a single domain is probably too coarse and noisy. For now I think it makes sense to let them do their own thing using g_log_default_handler() and continue using the G_MESSAGES_DEBUG mechanism with specific domains for each individual dissector. In the future a mechanism may be added to selectively enable these domains at runtime while trying to avoid the problems introduced by G_MESSAGES_DEBUG.
2021-06-08 01:46:52 +00:00
ws_debug("Could not create stderr handle");
ws_pipe: fix return value of ws_pipe_spawn_async on error path The function returns a GPid, not a gboolean. Callers (mmdbresolv and extcap) only assume WS_INVALID_PID to be invalid (as documented). Change-Id: I40b491272a451f569864fa3259009d6d3fcce772 Fixes: v2.5.1rc0-413-g1a0987904f ("Generalize our process spawning code.") Reviewed-on: https://code.wireshark.org/review/32933 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-21 20:17:45 +00:00
return WS_INVALID_PID;
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
}
win32-utils: Explicitly list inherited handles Windows processes inherit all inheritable handles when a new process is created using CreateProcess() with bInheritHandles set to TRUE. This can lead to undesired object lifetime extension. That is, the child process will keep ineritable handles alive even if it does not use them. Up to Windows Vista it was not possible explicitly list handles that should be inherited. Wireshark no longer works on Windows releases earlier than Vista, so use the new API without checking Windows version. Require all callers to win32_create_process() to pass in the list of handles to inherit. Set the listed handles as inheritable shortly before calling CreateProcess() and set them as not inheritable shortly after the process is created. This minimizes possibility for other callers (especially in 3rd party libraries) to inherit handles by accident. Do not terminate mmdbresolve process on exit. Instead rely on process exit when EOF is received on standard input. Previously the EOF was never received because mmdbresolve inherited both ends of standard input pipe, i.e. the fact that Wireshark closed the write end was not observed by mmdbresolve because mmdbresolve kept write handle the standard input pipe open.
2022-08-15 08:51:20 +00:00
inherit_handles[0] = child_stdin_rd;
inherit_handles[1] = child_stderr_wr;
inherit_handles[2] = child_stdout_wr;
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
memset(&processInfo, 0, sizeof(PROCESS_INFORMATION));
memset(&info, 0, sizeof(STARTUPINFO));
info.cb = sizeof(STARTUPINFO);
info.hStdInput = child_stdin_rd;
info.hStdError = child_stderr_wr;
info.hStdOutput = child_stdout_wr;
info.dwFlags = STARTF_USESTDHANDLES | STARTF_USESHOWWINDOW;
info.wShowWindow = SW_HIDE;
win32-utils: Explicitly list inherited handles Windows processes inherit all inheritable handles when a new process is created using CreateProcess() with bInheritHandles set to TRUE. This can lead to undesired object lifetime extension. That is, the child process will keep ineritable handles alive even if it does not use them. Up to Windows Vista it was not possible explicitly list handles that should be inherited. Wireshark no longer works on Windows releases earlier than Vista, so use the new API without checking Windows version. Require all callers to win32_create_process() to pass in the list of handles to inherit. Set the listed handles as inheritable shortly before calling CreateProcess() and set them as not inheritable shortly after the process is created. This minimizes possibility for other callers (especially in 3rd party libraries) to inherit handles by accident. Do not terminate mmdbresolve process on exit. Instead rely on process exit when EOF is received on standard input. Previously the EOF was never received because mmdbresolve inherited both ends of standard input pipe, i.e. the fact that Wireshark closed the write end was not observed by mmdbresolve because mmdbresolve kept write handle the standard input pipe open.
2022-08-15 08:51:20 +00:00
if (win32_create_process(NULL, command_line, NULL, NULL, G_N_ELEMENTS(inherit_handles), inherit_handles,
CREATE_NEW_CONSOLE, NULL, NULL, &info, &processInfo))
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
{
wsutil: Use GIOChannel for standard pipes Remove ws_read_string_from_pipe() as this function encourages bad design and is no longer necessary. Extcap stderr is read only after the child process has finished and thus the read will never block. Close process information thread handle right away as we don't use it. Remove unused ws_pipe_t member variables.
2022-08-07 14:12:24 +00:00
stdin_fd = _open_osfhandle((intptr_t)(child_stdin_wr), _O_BINARY);
stdout_fd = _open_osfhandle((intptr_t)(child_stdout_rd), _O_BINARY);
stderr_fd = _open_osfhandle((intptr_t)(child_stderr_rd), _O_BINARY);
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
pid = processInfo.hProcess;
wsutil: Use GIOChannel for standard pipes Remove ws_read_string_from_pipe() as this function encourages bad design and is no longer necessary. Extcap stderr is read only after the child process has finished and thus the read will never block. Close process information thread handle right away as we don't use it. Remove unused ws_pipe_t member variables.
2022-08-07 14:12:24 +00:00
CloseHandle(processInfo.hThread);
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
}
Win32: Fix child process pipe handle leaks Close pipe handles when spawning asynchronous processes, so only the child process holds handle to the other end of the pipe. Closing the handles makes it possible to use pipes the same way as on other OS, that is to rely on blocking read() to end when child process finishes. Do not call CloseHandle() on signal pipe in capture sync after the handle ownership was transferred to file descriptor. Close the file descriptor instead.
2022-07-15 16:16:39 +00:00
else
{
CloseHandle(child_stdin_wr);
CloseHandle(child_stdout_rd);
CloseHandle(child_stderr_rd);
}
/* We no longer need other (child) end of pipes. The child process holds
* its own handles that will be closed on process exit. However, we have
* to close *our* handles as otherwise read() on stdout_fd and stderr_fd
* will block indefinitely after the process exits.
*/
CloseHandle(child_stdin_rd);
CloseHandle(child_stdout_wr);
CloseHandle(child_stderr_wr);
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
#else
Allow trace of sync spawns When Wireshark uses a synchronous spawn (e.g., to launch an extcap) it would be nice to be able to see what command line is constructed to launch the process, and to see what comes back. The output will go to the g_log. Change-Id: Iec6baeebc026cd80398084c9644fc916ab068e2f Reviewed-on: https://code.wireshark.org/review/30475 Petri-Dish: Dario Lombardo <lomato@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Peter Wu <peter@lekensteyn.nl>
2018-11-01 16:20:47 +00:00
More spawned process handling updates. Document ws_pipe.h. Define invalid PIDs in one place. Extcap didn't use stdin before 1a0987904f. Make sure we close it. Change-Id: I7a69cd9b5137ae82435e64628a22e4d812d58f89 Reviewed-on: https://code.wireshark.org/review/26226 Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Gerald Combs <gerald@wireshark.org>
2018-03-02 17:11:31 +00:00
GError *error = NULL;
ws_pipe_spawn_*: fix deadlock in g_spawn on Linux with threads The deadlock can be observed with a slow malloc implementation, e.g. ASAN_OPTIONS=fast_unwind_on_malloc=0 tshark --version (This calls extcap_run_all which uses threads and ws_pipe_spawn_sync.) Change-Id: Iff329c465c53ed177980368cd645f59222f88dd3 Reviewed-on: https://code.wireshark.org/review/30777 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-11-24 14:20:22 +00:00
GSpawnFlags flags = G_SPAWN_DO_NOT_REAP_CHILD;
GSpawnChildSetupFunc child_setup = NULL;
#ifdef HAS_G_SPAWN_LINUX_THREAD_SAFETY_BUG
flags = (GSpawnFlags)(flags | G_SPAWN_LEAVE_DESCRIPTORS_OPEN);
child_setup = close_non_standard_fds_linux;
#endif
ws_pipe: fix memory leaks in spawn arguments handling On Windows, ws_pipe_spawn_sync always leaks 'winargs', and leaks 'argv' on some error paths. Fix these and refactor the common argument parsing functionality to reduce duplication of functionality. Change-Id: I8fa5ca45aec20b53f6fa243b0dd07241a345f7ab Reviewed-on: https://code.wireshark.org/review/32932 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Peter Wu <peter@lekensteyn.nl>
2019-04-21 18:48:11 +00:00
gboolean spawned = g_spawn_async_with_pipes(NULL, argv, NULL,
ws_pipe_spawn_*: fix deadlock in g_spawn on Linux with threads The deadlock can be observed with a slow malloc implementation, e.g. ASAN_OPTIONS=fast_unwind_on_malloc=0 tshark --version (This calls extcap_run_all which uses threads and ws_pipe_spawn_sync.) Change-Id: Iff329c465c53ed177980368cd645f59222f88dd3 Reviewed-on: https://code.wireshark.org/review/30777 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-11-24 14:20:22 +00:00
flags, child_setup, NULL,
wsutil: Use GIOChannel for standard pipes Remove ws_read_string_from_pipe() as this function encourages bad design and is no longer necessary. Extcap stderr is read only after the child process has finished and thus the read will never block. Close process information thread handle right away as we don't use it. Remove unused ws_pipe_t member variables.
2022-08-07 14:12:24 +00:00
&pid, &stdin_fd, &stdout_fd, &stderr_fd, &error);
More spawned process handling updates. Document ws_pipe.h. Define invalid PIDs in one place. Extcap didn't use stdin before 1a0987904f. Make sure we close it. Change-Id: I7a69cd9b5137ae82435e64628a22e4d812d58f89 Reviewed-on: https://code.wireshark.org/review/26226 Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Gerald Combs <gerald@wireshark.org>
2018-03-02 17:11:31 +00:00
if (!spawned) {
Refactor our logging and extend the wslog API Experience has shown that: 1. The current logging methods are not very reliable or practical. A logging bitmask makes little sense as the user-facing interface (who would want debug but not crtical messages for example?); it's computer-friendly and user-unfriendly. More importantly the console log level preference is initialized too late in the startup process to be used for the logging subsystem and that fact raises a number of annoying and hard-to-fix usability issues. 2. Coding around G_MESSAGES_DEBUG to comply with our log level mask and not clobber the user's settings or not create unexpected log misses is unworkable and generally follows the principle of most surprise. The fact that G_MESSAGES_DEBUG="all" can leak to other programs using GLib is also annoying. 3. The non-structured GLib logging API is very opinionated and lacks configurability beyond replacing the log handler. 4. Windows GUI has some special code to attach to a console, but it would be nice to abstract away the rest under a single interface. 5. Using this logger seems to be noticeably faster. Deprecate the console log level preference and extend our API to implement a log handler in wsutil/wslog.h to provide easy-to-use, flexible and dependable logging during all execution phases. Log levels have a hierarchy, from most verbose to least verbose (debug to error). When a given level is set everything above that is also enabled. The log level can be set with an environment variable or a command line option (parsed as soon as possible but still later than the environment). The default log level is "message". Dissector logging is not included because it is not clear what log domain they should use. An explosion to thousands of domains is not desirable and putting everything in a single domain is probably too coarse and noisy. For now I think it makes sense to let them do their own thing using g_log_default_handler() and continue using the G_MESSAGES_DEBUG mechanism with specific domains for each individual dissector. In the future a mechanism may be added to selectively enable these domains at runtime while trying to avoid the problems introduced by G_MESSAGES_DEBUG.
2021-06-08 01:46:52 +00:00
ws_debug("Error creating async pipe: %s", error->message);
More spawned process handling updates. Document ws_pipe.h. Define invalid PIDs in one place. Extcap didn't use stdin before 1a0987904f. Make sure we close it. Change-Id: I7a69cd9b5137ae82435e64628a22e4d812d58f89 Reviewed-on: https://code.wireshark.org/review/26226 Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Gerald Combs <gerald@wireshark.org>
2018-03-02 17:11:31 +00:00
g_free(error->message);
}
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
#endif
ws_pipe: fix memory leaks in spawn arguments handling On Windows, ws_pipe_spawn_sync always leaks 'winargs', and leaks 'argv' on some error paths. Fix these and refactor the common argument parsing functionality to reduce duplication of functionality. Change-Id: I8fa5ca45aec20b53f6fa243b0dd07241a345f7ab Reviewed-on: https://code.wireshark.org/review/32932 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Peter Wu <peter@lekensteyn.nl>
2019-04-21 18:48:11 +00:00
g_free(command_line);
g_strfreev(argv);
Allow trace of sync spawns When Wireshark uses a synchronous spawn (e.g., to launch an extcap) it would be nice to be able to see what command line is constructed to launch the process, and to see what comes back. The output will go to the g_log. Change-Id: Iec6baeebc026cd80398084c9644fc916ab068e2f Reviewed-on: https://code.wireshark.org/review/30475 Petri-Dish: Dario Lombardo <lomato@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Peter Wu <peter@lekensteyn.nl>
2018-11-01 16:20:47 +00:00
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
ws_pipe->pid = pid;
wsutil: Use GIOChannel for standard pipes Remove ws_read_string_from_pipe() as this function encourages bad design and is no longer necessary. Extcap stderr is read only after the child process has finished and thus the read will never block. Close process information thread handle right away as we don't use it. Remove unused ws_pipe_t member variables.
2022-08-07 14:12:24 +00:00
if (pid != WS_INVALID_PID) {
#ifdef _WIN32
ws_pipe->stdin_io = g_io_channel_win32_new_fd(stdin_fd);
ws_pipe->stdout_io = g_io_channel_win32_new_fd(stdout_fd);
ws_pipe->stderr_io = g_io_channel_win32_new_fd(stderr_fd);
#else
ws_pipe->stdin_io = g_io_channel_unix_new(stdin_fd);
ws_pipe->stdout_io = g_io_channel_unix_new(stdout_fd);
ws_pipe->stderr_io = g_io_channel_unix_new(stderr_fd);
#endif
g_io_channel_set_encoding(ws_pipe->stdin_io, NULL, NULL);
g_io_channel_set_encoding(ws_pipe->stdout_io, NULL, NULL);
g_io_channel_set_encoding(ws_pipe->stderr_io, NULL, NULL);
g_io_channel_set_buffered(ws_pipe->stdin_io, FALSE);
g_io_channel_set_buffered(ws_pipe->stdout_io, FALSE);
g_io_channel_set_buffered(ws_pipe->stderr_io, FALSE);
g_io_channel_set_close_on_unref(ws_pipe->stdin_io, TRUE);
g_io_channel_set_close_on_unref(ws_pipe->stdout_io, TRUE);
g_io_channel_set_close_on_unref(ws_pipe->stderr_io, TRUE);
}
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
return pid;
}
#ifdef _WIN32
typedef struct
{
HANDLE pipeHandle;
OVERLAPPED ol;
BOOL pendingIO;
} PIPEINTS;
gboolean
ws_pipe_wait_for_pipe(HANDLE * pipe_handles, int num_pipe_handles, HANDLE pid)
{
PIPEINTS pipeinsts[3];
HANDLE handles[4];
wsutil: Refactor WIN32 ws_pipe_wait_for_pipe() The ws_pipe_wait_for_pipe() implementation had multiple issues: * Use auto-reset events with ConnectNamedPipe (should be manual-reset) * Leaking event handles * Not checking return value from CreateEvent() * Waiting on closed handles This change fixes all the above mentioned issues. Bug: 15696 Change-Id: Ia0c389a902655f85eccb0c59288b4a7d49da48c9 Reviewed-on: https://code.wireshark.org/review/32896 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-19 14:08:46 +00:00
gboolean result = TRUE;
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
ws_pipe: Zero an array. Make sure we zero-initialize pipeinsts, otherwise ConnectNamedPipe will have indeterminate behavior according to the MSDN documentation for the OVERLAPPED structure. Change-Id: I38d9680cf01b0a8f9e566a85a7a330f6c0aa9a48 Ping-Bug: 14532 Reviewed-on: https://code.wireshark.org/review/26784 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-04-07 05:36:31 +00:00
SecureZeroMemory(pipeinsts, sizeof(pipeinsts));
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
if (num_pipe_handles == 0 || num_pipe_handles > 3)
{
Refactor our logging and extend the wslog API Experience has shown that: 1. The current logging methods are not very reliable or practical. A logging bitmask makes little sense as the user-facing interface (who would want debug but not crtical messages for example?); it's computer-friendly and user-unfriendly. More importantly the console log level preference is initialized too late in the startup process to be used for the logging subsystem and that fact raises a number of annoying and hard-to-fix usability issues. 2. Coding around G_MESSAGES_DEBUG to comply with our log level mask and not clobber the user's settings or not create unexpected log misses is unworkable and generally follows the principle of most surprise. The fact that G_MESSAGES_DEBUG="all" can leak to other programs using GLib is also annoying. 3. The non-structured GLib logging API is very opinionated and lacks configurability beyond replacing the log handler. 4. Windows GUI has some special code to attach to a console, but it would be nice to abstract away the rest under a single interface. 5. Using this logger seems to be noticeably faster. Deprecate the console log level preference and extend our API to implement a log handler in wsutil/wslog.h to provide easy-to-use, flexible and dependable logging during all execution phases. Log levels have a hierarchy, from most verbose to least verbose (debug to error). When a given level is set everything above that is also enabled. The log level can be set with an environment variable or a command line option (parsed as soon as possible but still later than the environment). The default log level is "message". Dissector logging is not included because it is not clear what log domain they should use. An explosion to thousands of domains is not desirable and putting everything in a single domain is probably too coarse and noisy. For now I think it makes sense to let them do their own thing using g_log_default_handler() and continue using the G_MESSAGES_DEBUG mechanism with specific domains for each individual dissector. In the future a mechanism may be added to selectively enable these domains at runtime while trying to avoid the problems introduced by G_MESSAGES_DEBUG.
2021-06-08 01:46:52 +00:00
ws_debug("Invalid number of pipes given as argument.");
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
return FALSE;
}
for (int i = 0; i < num_pipe_handles; ++i)
{
wsutil: Refactor WIN32 ws_pipe_wait_for_pipe() The ws_pipe_wait_for_pipe() implementation had multiple issues: * Use auto-reset events with ConnectNamedPipe (should be manual-reset) * Leaking event handles * Not checking return value from CreateEvent() * Waiting on closed handles This change fixes all the above mentioned issues. Bug: 15696 Change-Id: Ia0c389a902655f85eccb0c59288b4a7d49da48c9 Reviewed-on: https://code.wireshark.org/review/32896 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-19 14:08:46 +00:00
pipeinsts[i].ol.hEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
if (!pipeinsts[i].ol.hEvent)
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
{
Refactor our logging and extend the wslog API Experience has shown that: 1. The current logging methods are not very reliable or practical. A logging bitmask makes little sense as the user-facing interface (who would want debug but not crtical messages for example?); it's computer-friendly and user-unfriendly. More importantly the console log level preference is initialized too late in the startup process to be used for the logging subsystem and that fact raises a number of annoying and hard-to-fix usability issues. 2. Coding around G_MESSAGES_DEBUG to comply with our log level mask and not clobber the user's settings or not create unexpected log misses is unworkable and generally follows the principle of most surprise. The fact that G_MESSAGES_DEBUG="all" can leak to other programs using GLib is also annoying. 3. The non-structured GLib logging API is very opinionated and lacks configurability beyond replacing the log handler. 4. Windows GUI has some special code to attach to a console, but it would be nice to abstract away the rest under a single interface. 5. Using this logger seems to be noticeably faster. Deprecate the console log level preference and extend our API to implement a log handler in wsutil/wslog.h to provide easy-to-use, flexible and dependable logging during all execution phases. Log levels have a hierarchy, from most verbose to least verbose (debug to error). When a given level is set everything above that is also enabled. The log level can be set with an environment variable or a command line option (parsed as soon as possible but still later than the environment). The default log level is "message". Dissector logging is not included because it is not clear what log domain they should use. An explosion to thousands of domains is not desirable and putting everything in a single domain is probably too coarse and noisy. For now I think it makes sense to let them do their own thing using g_log_default_handler() and continue using the G_MESSAGES_DEBUG mechanism with specific domains for each individual dissector. In the future a mechanism may be added to selectively enable these domains at runtime while trying to avoid the problems introduced by G_MESSAGES_DEBUG.
2021-06-08 01:46:52 +00:00
ws_debug("Could not create overlapped event");
wsutil: Refactor WIN32 ws_pipe_wait_for_pipe() The ws_pipe_wait_for_pipe() implementation had multiple issues: * Use auto-reset events with ConnectNamedPipe (should be manual-reset) * Leaking event handles * Not checking return value from CreateEvent() * Waiting on closed handles This change fixes all the above mentioned issues. Bug: 15696 Change-Id: Ia0c389a902655f85eccb0c59288b4a7d49da48c9 Reviewed-on: https://code.wireshark.org/review/32896 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-19 14:08:46 +00:00
for (int j = 0; j < i; j++)
{
CloseHandle(pipeinsts[j].ol.hEvent);
}
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
return FALSE;
}
wsutil: Refactor WIN32 ws_pipe_wait_for_pipe() The ws_pipe_wait_for_pipe() implementation had multiple issues: * Use auto-reset events with ConnectNamedPipe (should be manual-reset) * Leaking event handles * Not checking return value from CreateEvent() * Waiting on closed handles This change fixes all the above mentioned issues. Bug: 15696 Change-Id: Ia0c389a902655f85eccb0c59288b4a7d49da48c9 Reviewed-on: https://code.wireshark.org/review/32896 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-19 14:08:46 +00:00
}
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
wsutil: Refactor WIN32 ws_pipe_wait_for_pipe() The ws_pipe_wait_for_pipe() implementation had multiple issues: * Use auto-reset events with ConnectNamedPipe (should be manual-reset) * Leaking event handles * Not checking return value from CreateEvent() * Waiting on closed handles This change fixes all the above mentioned issues. Bug: 15696 Change-Id: Ia0c389a902655f85eccb0c59288b4a7d49da48c9 Reviewed-on: https://code.wireshark.org/review/32896 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-19 14:08:46 +00:00
for (int i = 0; i < num_pipe_handles; ++i)
{
pipeinsts[i].pipeHandle = pipe_handles[i];
pipeinsts[i].ol.Pointer = 0;
pipeinsts[i].pendingIO = FALSE;
if (!ConnectNamedPipe(pipeinsts[i].pipeHandle, &pipeinsts[i].ol))
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
{
wsutil: Refactor WIN32 ws_pipe_wait_for_pipe() The ws_pipe_wait_for_pipe() implementation had multiple issues: * Use auto-reset events with ConnectNamedPipe (should be manual-reset) * Leaking event handles * Not checking return value from CreateEvent() * Waiting on closed handles This change fixes all the above mentioned issues. Bug: 15696 Change-Id: Ia0c389a902655f85eccb0c59288b4a7d49da48c9 Reviewed-on: https://code.wireshark.org/review/32896 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-19 14:08:46 +00:00
DWORD error = GetLastError();
switch (error)
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
{
wsutil: Refactor WIN32 ws_pipe_wait_for_pipe() The ws_pipe_wait_for_pipe() implementation had multiple issues: * Use auto-reset events with ConnectNamedPipe (should be manual-reset) * Leaking event handles * Not checking return value from CreateEvent() * Waiting on closed handles This change fixes all the above mentioned issues. Bug: 15696 Change-Id: Ia0c389a902655f85eccb0c59288b4a7d49da48c9 Reviewed-on: https://code.wireshark.org/review/32896 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-19 14:08:46 +00:00
case ERROR_IO_PENDING:
pipeinsts[i].pendingIO = TRUE;
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
break;
wsutil: Refactor WIN32 ws_pipe_wait_for_pipe() The ws_pipe_wait_for_pipe() implementation had multiple issues: * Use auto-reset events with ConnectNamedPipe (should be manual-reset) * Leaking event handles * Not checking return value from CreateEvent() * Waiting on closed handles This change fixes all the above mentioned issues. Bug: 15696 Change-Id: Ia0c389a902655f85eccb0c59288b4a7d49da48c9 Reviewed-on: https://code.wireshark.org/review/32896 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-19 14:08:46 +00:00
case ERROR_PIPE_CONNECTED:
SetEvent(pipeinsts[i].ol.hEvent);
break;
default:
MinGW: Fix -Wformat
2023-01-12 03:43:59 +00:00
ws_debug("ConnectNamedPipe failed with %ld\n.", error);
wsutil: Refactor WIN32 ws_pipe_wait_for_pipe() The ws_pipe_wait_for_pipe() implementation had multiple issues: * Use auto-reset events with ConnectNamedPipe (should be manual-reset) * Leaking event handles * Not checking return value from CreateEvent() * Waiting on closed handles This change fixes all the above mentioned issues. Bug: 15696 Change-Id: Ia0c389a902655f85eccb0c59288b4a7d49da48c9 Reviewed-on: https://code.wireshark.org/review/32896 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-19 14:08:46 +00:00
result = FALSE;
}
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
}
}
wsutil: Refactor WIN32 ws_pipe_wait_for_pipe() The ws_pipe_wait_for_pipe() implementation had multiple issues: * Use auto-reset events with ConnectNamedPipe (should be manual-reset) * Leaking event handles * Not checking return value from CreateEvent() * Waiting on closed handles This change fixes all the above mentioned issues. Bug: 15696 Change-Id: Ia0c389a902655f85eccb0c59288b4a7d49da48c9 Reviewed-on: https://code.wireshark.org/review/32896 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-19 14:08:46 +00:00
while (result)
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
{
wsutil: Refactor WIN32 ws_pipe_wait_for_pipe() The ws_pipe_wait_for_pipe() implementation had multiple issues: * Use auto-reset events with ConnectNamedPipe (should be manual-reset) * Leaking event handles * Not checking return value from CreateEvent() * Waiting on closed handles This change fixes all the above mentioned issues. Bug: 15696 Change-Id: Ia0c389a902655f85eccb0c59288b4a7d49da48c9 Reviewed-on: https://code.wireshark.org/review/32896 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-19 14:08:46 +00:00
DWORD dw;
int num_handles = 0;
for (int i = 0; i < num_pipe_handles; ++i)
{
if (pipeinsts[i].pendingIO)
{
handles[num_handles] = pipeinsts[i].ol.hEvent;
num_handles++;
}
}
if (num_handles == 0)
{
/* All pipes have been successfully connected */
break;
}
/* Wait for process in case it exits before the pipes have connected */
handles[num_handles] = pid;
wsutil: Fix 30 seconds freeze if process fails to start In ws_pipe_wait_for_pipe() on Windows, the WaitForMultipleObjects() waits on the pending pipe connection events and process handle. If the process handle is signalled, then it means that the process did exit without connecting to the pipes. The WaitForMultipleObjects() was not waiting on the process handle and thus if the process did fail without connecting to pipes the Wireshark gui was frozen for 30 seconds. This change fixes the freeze by increasing the number of handles, so WaitForMultipleObjects() is aware of the process handle. Change-Id: Id13824a60baf4be7795cbe1d5ed1c7932edbff45 Reviewed-on: https://code.wireshark.org/review/33028 Reviewed-by: Gerald Combs <gerald@wireshark.org>
2019-04-30 13:52:38 +00:00
num_handles++;
wsutil: Refactor WIN32 ws_pipe_wait_for_pipe() The ws_pipe_wait_for_pipe() implementation had multiple issues: * Use auto-reset events with ConnectNamedPipe (should be manual-reset) * Leaking event handles * Not checking return value from CreateEvent() * Waiting on closed handles This change fixes all the above mentioned issues. Bug: 15696 Change-Id: Ia0c389a902655f85eccb0c59288b4a7d49da48c9 Reviewed-on: https://code.wireshark.org/review/32896 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-19 14:08:46 +00:00
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
dw = WaitForMultipleObjects(num_handles, handles, FALSE, 30000);
wsutil: Refactor WIN32 ws_pipe_wait_for_pipe() The ws_pipe_wait_for_pipe() implementation had multiple issues: * Use auto-reset events with ConnectNamedPipe (should be manual-reset) * Leaking event handles * Not checking return value from CreateEvent() * Waiting on closed handles This change fixes all the above mentioned issues. Bug: 15696 Change-Id: Ia0c389a902655f85eccb0c59288b4a7d49da48c9 Reviewed-on: https://code.wireshark.org/review/32896 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-19 14:08:46 +00:00
int handle_idx = dw - WAIT_OBJECT_0;
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
if (dw == WAIT_TIMEOUT)
{
Refactor our logging and extend the wslog API Experience has shown that: 1. The current logging methods are not very reliable or practical. A logging bitmask makes little sense as the user-facing interface (who would want debug but not crtical messages for example?); it's computer-friendly and user-unfriendly. More importantly the console log level preference is initialized too late in the startup process to be used for the logging subsystem and that fact raises a number of annoying and hard-to-fix usability issues. 2. Coding around G_MESSAGES_DEBUG to comply with our log level mask and not clobber the user's settings or not create unexpected log misses is unworkable and generally follows the principle of most surprise. The fact that G_MESSAGES_DEBUG="all" can leak to other programs using GLib is also annoying. 3. The non-structured GLib logging API is very opinionated and lacks configurability beyond replacing the log handler. 4. Windows GUI has some special code to attach to a console, but it would be nice to abstract away the rest under a single interface. 5. Using this logger seems to be noticeably faster. Deprecate the console log level preference and extend our API to implement a log handler in wsutil/wslog.h to provide easy-to-use, flexible and dependable logging during all execution phases. Log levels have a hierarchy, from most verbose to least verbose (debug to error). When a given level is set everything above that is also enabled. The log level can be set with an environment variable or a command line option (parsed as soon as possible but still later than the environment). The default log level is "message". Dissector logging is not included because it is not clear what log domain they should use. An explosion to thousands of domains is not desirable and putting everything in a single domain is probably too coarse and noisy. For now I think it makes sense to let them do their own thing using g_log_default_handler() and continue using the G_MESSAGES_DEBUG mechanism with specific domains for each individual dissector. In the future a mechanism may be added to selectively enable these domains at runtime while trying to avoid the problems introduced by G_MESSAGES_DEBUG.
2021-06-08 01:46:52 +00:00
ws_debug("extcap didn't connect to pipe within 30 seconds.");
wsutil: Refactor WIN32 ws_pipe_wait_for_pipe() The ws_pipe_wait_for_pipe() implementation had multiple issues: * Use auto-reset events with ConnectNamedPipe (should be manual-reset) * Leaking event handles * Not checking return value from CreateEvent() * Waiting on closed handles This change fixes all the above mentioned issues. Bug: 15696 Change-Id: Ia0c389a902655f85eccb0c59288b4a7d49da48c9 Reviewed-on: https://code.wireshark.org/review/32896 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-19 14:08:46 +00:00
result = FALSE;
break;
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
}
// If index points to our handles array
wsutil: Refactor WIN32 ws_pipe_wait_for_pipe() The ws_pipe_wait_for_pipe() implementation had multiple issues: * Use auto-reset events with ConnectNamedPipe (should be manual-reset) * Leaking event handles * Not checking return value from CreateEvent() * Waiting on closed handles This change fixes all the above mentioned issues. Bug: 15696 Change-Id: Ia0c389a902655f85eccb0c59288b4a7d49da48c9 Reviewed-on: https://code.wireshark.org/review/32896 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-19 14:08:46 +00:00
else if (handle_idx >= 0 && handle_idx < num_handles)
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
{
wsutil: Refactor WIN32 ws_pipe_wait_for_pipe() The ws_pipe_wait_for_pipe() implementation had multiple issues: * Use auto-reset events with ConnectNamedPipe (should be manual-reset) * Leaking event handles * Not checking return value from CreateEvent() * Waiting on closed handles This change fixes all the above mentioned issues. Bug: 15696 Change-Id: Ia0c389a902655f85eccb0c59288b4a7d49da48c9 Reviewed-on: https://code.wireshark.org/review/32896 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-19 14:08:46 +00:00
if (handles[handle_idx] == pid)
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
{
Refactor our logging and extend the wslog API Experience has shown that: 1. The current logging methods are not very reliable or practical. A logging bitmask makes little sense as the user-facing interface (who would want debug but not crtical messages for example?); it's computer-friendly and user-unfriendly. More importantly the console log level preference is initialized too late in the startup process to be used for the logging subsystem and that fact raises a number of annoying and hard-to-fix usability issues. 2. Coding around G_MESSAGES_DEBUG to comply with our log level mask and not clobber the user's settings or not create unexpected log misses is unworkable and generally follows the principle of most surprise. The fact that G_MESSAGES_DEBUG="all" can leak to other programs using GLib is also annoying. 3. The non-structured GLib logging API is very opinionated and lacks configurability beyond replacing the log handler. 4. Windows GUI has some special code to attach to a console, but it would be nice to abstract away the rest under a single interface. 5. Using this logger seems to be noticeably faster. Deprecate the console log level preference and extend our API to implement a log handler in wsutil/wslog.h to provide easy-to-use, flexible and dependable logging during all execution phases. Log levels have a hierarchy, from most verbose to least verbose (debug to error). When a given level is set everything above that is also enabled. The log level can be set with an environment variable or a command line option (parsed as soon as possible but still later than the environment). The default log level is "message". Dissector logging is not included because it is not clear what log domain they should use. An explosion to thousands of domains is not desirable and putting everything in a single domain is probably too coarse and noisy. For now I think it makes sense to let them do their own thing using g_log_default_handler() and continue using the G_MESSAGES_DEBUG mechanism with specific domains for each individual dissector. In the future a mechanism may be added to selectively enable these domains at runtime while trying to avoid the problems introduced by G_MESSAGES_DEBUG.
2021-06-08 01:46:52 +00:00
ws_debug("extcap terminated without connecting to pipe.");
wsutil: Refactor WIN32 ws_pipe_wait_for_pipe() The ws_pipe_wait_for_pipe() implementation had multiple issues: * Use auto-reset events with ConnectNamedPipe (should be manual-reset) * Leaking event handles * Not checking return value from CreateEvent() * Waiting on closed handles This change fixes all the above mentioned issues. Bug: 15696 Change-Id: Ia0c389a902655f85eccb0c59288b4a7d49da48c9 Reviewed-on: https://code.wireshark.org/review/32896 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-19 14:08:46 +00:00
result = FALSE;
}
for (int i = 0; i < num_pipe_handles; ++i)
{
if (handles[handle_idx] == pipeinsts[i].ol.hEvent)
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
{
wsutil: Refactor WIN32 ws_pipe_wait_for_pipe() The ws_pipe_wait_for_pipe() implementation had multiple issues: * Use auto-reset events with ConnectNamedPipe (should be manual-reset) * Leaking event handles * Not checking return value from CreateEvent() * Waiting on closed handles This change fixes all the above mentioned issues. Bug: 15696 Change-Id: Ia0c389a902655f85eccb0c59288b4a7d49da48c9 Reviewed-on: https://code.wireshark.org/review/32896 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-19 14:08:46 +00:00
DWORD cbRet;
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
BOOL success = GetOverlappedResult(
wsutil: Refactor WIN32 ws_pipe_wait_for_pipe() The ws_pipe_wait_for_pipe() implementation had multiple issues: * Use auto-reset events with ConnectNamedPipe (should be manual-reset) * Leaking event handles * Not checking return value from CreateEvent() * Waiting on closed handles This change fixes all the above mentioned issues. Bug: 15696 Change-Id: Ia0c389a902655f85eccb0c59288b4a7d49da48c9 Reviewed-on: https://code.wireshark.org/review/32896 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-19 14:08:46 +00:00
pipeinsts[i].pipeHandle, // handle to pipe
&pipeinsts[i].ol, // OVERLAPPED structure
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
&cbRet, // bytes transferred
wsutil: Refactor WIN32 ws_pipe_wait_for_pipe() The ws_pipe_wait_for_pipe() implementation had multiple issues: * Use auto-reset events with ConnectNamedPipe (should be manual-reset) * Leaking event handles * Not checking return value from CreateEvent() * Waiting on closed handles This change fixes all the above mentioned issues. Bug: 15696 Change-Id: Ia0c389a902655f85eccb0c59288b4a7d49da48c9 Reviewed-on: https://code.wireshark.org/review/32896 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-19 14:08:46 +00:00
TRUE); // wait
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
if (!success)
{
MinGW: Fix -Wformat
2023-01-12 03:43:59 +00:00
ws_debug("Error %ld \n.", GetLastError());
wsutil: Refactor WIN32 ws_pipe_wait_for_pipe() The ws_pipe_wait_for_pipe() implementation had multiple issues: * Use auto-reset events with ConnectNamedPipe (should be manual-reset) * Leaking event handles * Not checking return value from CreateEvent() * Waiting on closed handles This change fixes all the above mentioned issues. Bug: 15696 Change-Id: Ia0c389a902655f85eccb0c59288b4a7d49da48c9 Reviewed-on: https://code.wireshark.org/review/32896 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-19 14:08:46 +00:00
result = FALSE;
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
}
wsutil: Refactor WIN32 ws_pipe_wait_for_pipe() The ws_pipe_wait_for_pipe() implementation had multiple issues: * Use auto-reset events with ConnectNamedPipe (should be manual-reset) * Leaking event handles * Not checking return value from CreateEvent() * Waiting on closed handles This change fixes all the above mentioned issues. Bug: 15696 Change-Id: Ia0c389a902655f85eccb0c59288b4a7d49da48c9 Reviewed-on: https://code.wireshark.org/review/32896 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-19 14:08:46 +00:00
pipeinsts[i].pendingIO = FALSE;
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
}
}
}
else
{
MinGW: Fix -Wformat
2023-01-12 03:43:59 +00:00
ws_debug("WaitForMultipleObjects returned 0x%08lX. Error %ld", dw, GetLastError());
wsutil: Refactor WIN32 ws_pipe_wait_for_pipe() The ws_pipe_wait_for_pipe() implementation had multiple issues: * Use auto-reset events with ConnectNamedPipe (should be manual-reset) * Leaking event handles * Not checking return value from CreateEvent() * Waiting on closed handles This change fixes all the above mentioned issues. Bug: 15696 Change-Id: Ia0c389a902655f85eccb0c59288b4a7d49da48c9 Reviewed-on: https://code.wireshark.org/review/32896 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-19 14:08:46 +00:00
result = FALSE;
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
}
}
wsutil: Refactor WIN32 ws_pipe_wait_for_pipe() The ws_pipe_wait_for_pipe() implementation had multiple issues: * Use auto-reset events with ConnectNamedPipe (should be manual-reset) * Leaking event handles * Not checking return value from CreateEvent() * Waiting on closed handles This change fixes all the above mentioned issues. Bug: 15696 Change-Id: Ia0c389a902655f85eccb0c59288b4a7d49da48c9 Reviewed-on: https://code.wireshark.org/review/32896 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Tomasz Moń <desowin@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-04-19 14:08:46 +00:00
for (int i = 0; i < num_pipe_handles; ++i)
{
if (pipeinsts[i].pendingIO)
{
CancelIoEx(pipeinsts[i].pipeHandle, &pipeinsts[i].ol);
WaitForSingleObject(pipeinsts[i].ol.hEvent, INFINITE);
}
CloseHandle(pipeinsts[i].ol.hEvent);
}
return result;
Generalize our process spawning code. Move the contents of extcap_spawn to ws_pipe. Rename various extcap_* prefixes to ws_pipe_*. Open stdin when we spawn processes. Change-Id: I9286295443ee955bb6328b0ed6f945ee0bb2a798 Reviewed-on: https://code.wireshark.org/review/26216 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-01 23:31:45 +00:00
}
#endif
Put special pipe-handling code into libwsutil. Ask, in a comment, why we're doing PeekNamedPipe() when we're trying to read everyting in the pipe, up to the EOF, into a string. On UN*X, do the same "read up to an EOF and then NUL-terminate the result" stuff that we did on Windows; nothing guarantees that, on all UN*Xes, in all circumstances, until the end of time, world without end, amen, we can do one read and get the entire string. Change-Id: I578802b23fec1051139eaefd9a09fe2a6de06a11 Reviewed-on: https://code.wireshark.org/review/24959 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Guy Harris <guy@alum.mit.edu>
2017-12-23 08:05:21 +00:00
gboolean
ws_pipe_data_available(int pipe_fd)
{
#ifdef _WIN32 /* PeekNamedPipe */
HANDLE hPipe = (HANDLE) _get_osfhandle(pipe_fd);
DWORD bytes_avail;
if (hPipe == INVALID_HANDLE_VALUE)
{
return FALSE;
}
if (! PeekNamedPipe(hPipe, NULL, 0, NULL, &bytes_avail, NULL))
{
return FALSE;
}
if (bytes_avail > 0)
{
return TRUE;
}
return FALSE;
#else /* select */
fd_set rfds;
struct timeval timeout;
FD_ZERO(&rfds);
FD_SET(pipe_fd, &rfds);
timeout.tv_sec = 0;
timeout.tv_usec = 0;
if (select(pipe_fd + 1, &rfds, NULL, NULL, &timeout) > 0)
{
return TRUE;
}
return FALSE;
#endif
}
/*
HTTPS (almost) everywhere. Change all wireshark.org URLs to use https. Fix some broken links while we're at it. Change-Id: I161bf8eeca43b8027605acea666032da86f5ea1c Reviewed-on: https://code.wireshark.org/review/34089 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2019-07-26 18:43:17 +00:00
* Editor modelines - https://www.wireshark.org/tools/modelines.html
Put special pipe-handling code into libwsutil. Ask, in a comment, why we're doing PeekNamedPipe() when we're trying to read everyting in the pipe, up to the EOF, into a string. On UN*X, do the same "read up to an EOF and then NUL-terminate the result" stuff that we did on Windows; nothing guarantees that, on all UN*Xes, in all circumstances, until the end of time, world without end, amen, we can do one read and get the entire string. Change-Id: I578802b23fec1051139eaefd9a09fe2a6de06a11 Reviewed-on: https://code.wireshark.org/review/24959 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Guy Harris <guy@alum.mit.edu>
2017-12-23 08:05:21 +00:00
*
* Local variables:
* c-basic-offset: 4
* tab-width: 8
* indent-tabs-mode: nil
* End:
*
* vi: set shiftwidth=4 tabstop=8 expandtab:
* :indentSize=4:tabSize=8:noTabs=true:
*/