There is no risk to resource leak i think, becase:
1. dup() in first statement (TTY controlling) duplicate console fd, so
marked as a resource leak a console fd is a false positive - primo:
it's console handler, secundo: dup() is using for child/fork
processes.
2. dup() in second statement for /d
[Michał Kulling]
> Coverity mark my changes as resource leak because I'm not assign
> descriptor returned from dup().
No, it mark them as resource leaks because the resources leak. The
opened file descriptor isn't closed. I suspect things will fail it it
is closed, so I have not tried to close i
Hi Petter!
Could you apply patch from attachment?
I added four new variables at the top of spawn() for TTY controlling and
duplicated /dev/null.
Coverity mark my changes as resource leak because I'm not assign
descriptor returned from dup().
Patch for rev 159.
Best regards, Mike.
[Mich
[Michał Kulling]
> Currently in spawn() function is using dup() without return code
> validation, i added simple check with additional output to stderr.
Thank you. Applied.
--
Happy hacking
Petter Reinholdtsen
Currently in spawn() function is using dup() without return code
validation, i added simple check with additional output to stderr.
--
Michal Kulling
--- init.c-orig 2014-02-10 21:07:17.066060632 +0100
+++ init.c 2014-02-10 21:09:08.518063280 +0100
@@ -1158,8 +1158,15 @@
if ((ftty = console
