> On May 9, 2017, at 02:38, Emeric Brun <[email protected]> wrote: > > Hi Grant, > > On 05/06/2017 12:41 AM, Grant Zhang wrote: >> Hi Emeric, >> >> Thanks for your review! Please see the updated patches and let me know if >> your comments have been properly addressed. >> >> Thanks, >> >> Grant >> >> >> >> >> >> >> >>> On May 2, 2017, at 04:49, Emeric Brun <[email protected]> wrote: >>> >>> Hi Grant, >>> >>> >>> An other issue: >>> >>> static void ssl_sock_close(struct connection *conn) { >>> >>> if (conn->xprt_ctx) { >>> if (global_ssl.async) { >>> /* the async fd is created and owned by the SSL >>> engine, which is >>> * responsible for fd closure. Here we are done with >>> the async fd >>> * thus disable the polling on it, as well as clean >>> up fdtab entry. >>> */ >>> fd_stop_both(conn->async_fd); >>> fdtab[conn->async_fd].async = 0; >>> fdtab[conn->async_fd].state = 0; >>> } >>> >>> >>> If yout configure ssl-async without an engine or filtering on a unused >>> algo. This code is >>> called with an uninitialized conn->async_fd, resulting some of the time >>> with a segfault. >>> >>> R, >>> Emeric >> > > The issue is still there: > +#if OPENSSL_VERSION_NUMBER >= 0x1010000fL > + if (openssl_engines_initialized && global_ssl.async) { > + /* the async fd is created and owned by the SSL engine, > which is > + * responsible for fd closure. Here we are done with > the async fd > + * thus disable the polling on it, as well as clean up > fdtab entry. > + */ > + fd_stop_both(conn->async_fd); > + fdtab[conn->async_fd].async = 0; > + fdtab[conn->async_fd].state = 0; > + } > +#endif > > If no WANT_ASYNC is returned, the 'conn->async_fd' could remain uninitialized > (for instance a conn witch doesn't use algo provided by the engine). A fix > would be to initialize global_ssl.async to '-1' and to test it. Now I see the issue, thanks. Wrt the fix, I might be missing something--I don't know how initialize global_ssl.async to -1 would fix the issue. Or do you mean initialize conn->async_fd to '-1'?
> I still have the daemonize issue: the main process stalled on a futex if dh > param 2048 is set: > > global > tune.ssl.default-dh-param 2048 > Hmm, I probably mixed "-d" with "-D" and thus couldn't repro the issue before. It looks like the main process stalls at DH_free(local_dh_1024) (part of __ssl_sock_deinit). Not sure why but I will debug and report back. Thanks, Grant
