Commits on Source (10)
-
This reverts commit 4aa885d4. Turns out the problem was not about dupping fds at all, but calling non-async-signal-safe functions like strdup() between fork() and exec() in the child process. For more discussion, see: wayland/weston!941 (comment 1457053) Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
e88a6224 -
Doing any kind of memory allocation calls between fork() and exec() in the child process is prone to deadlocks and explosions. In general, only async-signal-safe functions are safe there. Move the config access to the parent process before fork() to avoid problems. See also: wayland/weston!941 (comment 1457053) Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
71b40fc7 -
Between fork() and exec() in the child process it is only safe to use async-signal-safe functions. weston_log() definitely is not one, it allocates memory and does whatnot. weston_log() is also inappropriate for other reasons: the child process has its own stream buffers and flight-recorder. No-one looks into the child process' flight recorder, so messages would be lost there. The logging machinery might also attempt to write into debug streams, meaning both parent and child could be writing simultaneously. It seems that the best we can do is to pre-bake an error message and only write() it out if exec() fails. There is no mention that even strerror_r() might be safe to call, so we don't. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
77cf8cb0 -
fcntl(2) manual says the return type is int, and that F_SETFD takes an int. So use int. Noticed by code inspection. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
0260b8a0 -
This function will be used between fork() and exec() to remove the close-on-exec flag. The first user will be compositor/xwayland.c. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
99b2b958 -
Between fork() and exec() in the child process it is only safe to use async-signal-safe functions. Surprisingly, snprintf() is not such function. See e.g. https://stackoverflow.com/a/6771799 and how snprintf is not listed in signal-safety(7) manual. Therefore we must prepare the fd argument strings before fork(). That is only possible if we also do not dup() fd in the child process. Hence we remove the close-on-exec flag instead in the child process which has copies of the parent's file descriptors. Fortunately fcntl() is safe. struct fdstr is helping to reduce code clutter a bit. Additionally, if fork() fails, we now clean up the fds we created. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
4c0bdbfd -
We are already using pipe2() in many places, even in libweston, so let's simplify the code here as well - not to mention avoid a theoretical race. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
a3d7199b -
Constructing argv before-hand is a little easier to look at, but this is mostly just anticipating more changes to how Weston spawns processes in general. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
d1b01ffb -
Between fork() and exec() in the child process it is only safe to use async-signal-safe functions. Painfully, setenv() is not listed as such. Therefore we must craft our own custom environment, and we get no help from libc with that. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
1bd92dac -
Simplifies the code a bit. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
764c2aff