If execargs is not given in stunnel.conf, stunnel calls execvp with a NULL pointer as its second argument, which makes execvp fail with EFAIL. Fix: execargs should be mandatory (and checked on startup), or something like the following should be done in client.c: if (NULL == c->opt->execargs) { char *args[] = {c->opt->execname, NULL}; execvp(c->opt->execname, args); } else { execvp(c->opt->execname, c->opt->execargs); } How-To-Repeat: I wrapped popa3d with stunnel, which worked on 4.x (modulo the spurious broken connection errors I filed a while ago) without execargs in stunnel.conf. I copied my configuration, and now every connection attempt leads to stunnel[13279]: /usr/local/libexec/popa3d: Bad address (14)
Responsible Changed From-To: freebsd-ports-bugs->roam Over to maintainer
State Changed From-To: open->analyzed I'm looking into this...
Peter Pentchev wrote: > I'm looking into this... The sematics of execve changed a year ago, see http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_exec.c?f=h#rev1.238 This is the relevant part from execve(2): The argument argv is a pointer to a null-terminated array of character pointers to null-terminated character strings. These strings construct the argument list to be made available to the new process. At least one argument must be present in the array; by custom, the first element should be the name of the executed program (for example, the last compo- nent of path). Yours, Florian.
State Changed From-To: analyzed->closed Fixed in the just-committed update to 4.10. Thanks for the problem report and the analysis!