This patch fixes an issue where the exit handler is not called for the
given process_t in case CreateProcessA() fails. This could, for example,
happen if the user tries to execute a binary that does not exist.
See: https://bugs.torproject.org/31810
This patch removes a call to tor_assert_unreached() after execve()
failed. This assertion leads to the child process emitting a stack trace
on its standard output, which makes the error harder for the user to
demystify, since they think it is an internal error in Tor instead of
"just" being a "no such file or directory" error.
The process will now instead output "Error from child process: X" where
X is the stringified version of the errno value.
See: https://bugs.torproject.org/31810
We used to have this function so that we could mark our initial
log-to-stdout as specifically temporary so that we would delete it
once regular logs were configured. But it's no longer necessary to
mark these logs as temporary, since we now use a mark-and-sweep
process to ensure that _all_ not-configured logs are closed when we
change our configuration.
Instead, this function will be the basis of a refactoring in how we
handle default logs.
In case of error, a negative value will be returned or NULL written into
first supplied argument.
This patch uses both cases to comply with style in the specific files.
A tor_vasprintf error in process_vprintf would lead to a NULL dereference
later on in buf_add, because the return value -1 casted to size_t would
pass an assertion check inside of buf_add.
On the other hand, common systems will fail on such an operation, so it
is not a huge difference to a simple assertion. Yet it is better to
properly fail instead of relying on such behaviour on all systems.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
We have a getaddrinfo() implementation that we prefer, and a
gethostbyname*() implementation that we fall back on. Give them
both the same interface, and let them be called by the same name.
This is a preparatory step for making them both mockable.
The documentation for this function says that the smartlist can
contain NULLs, but the code only handled NULLs if they were at the
start of the list.
We didn't notice this for a long time, because when Tor is run
normally, the sequence of msg_id_t is densely packed, and so this
list (mapping msg_id_t to channel_id_t) contains no NULL elements.
We could only run into this bug:
* when Tor was running in embedded mode, and starting more than once.
* when Tor ran first with more pubsub messages enabled, and then
later with fewer.
* When the second run (the one with fewer enabled pubsub messages)
had at least some messages enabled, and those messages were not
the ones with numerically highest msg_id_t values.
Fixes bug 31898; bugfix on 47de9c7b0a
in 0.4.1.1-alpha.
There is a bad design choice in two of our configuration types,
where the empty string encodes a value that is not the same as the
default value. This design choice, plus an implementation mistake,
meant that config_dup() did not preserve the value of routerset_t,
and thereby caused bug #31495.
This comment-only patch documents the two types with the problem,
and suggests that implementors try to avoid it in the future.
Closes ticket 31907.
