Hello, I misread the code comment...My application is not likely to be closing this FD. AFAIK this is only possible via memory corruption, so that aside I'm pretty certain that this would be an "fd already closed" as you mentioned. The only message MHD gives is:
Fatal error in libmicrohttpd..."close failed". Should I check the system error by changing the MHD code or is there a way to get MHD to print the system error? Thanks much! M. On Thu, Jan 14, 2016 at 10:14 AM, Christian Grothoff <[email protected]> wrote: > On 01/14/2016 06:22 PM, A. Mark wrote: > > OS:Linux Fedora 20 x86_64 > > > > I'm getting the following segfault/abort: > > > > "close failed" from libmicrohttpd v0.9.46. > > > > I traced the issue to the following code in daemon.c: > > > > --- > > /* epoll documentation suggests that closing a FD > > automatically removes it from the epoll set; however, > > this is not true as if we fail to do manually remove it, > > we are still seeing an event for this fd in epoll, > > causing grief (use-after-free...) --- at least on my > > system. */ > > if (0 != epoll_ctl (daemon->epoll_fd, > > EPOLL_CTL_DEL, > > pos->socket_fd, > > NULL)) > > MHD_PANIC ("Failed to remove FD from epoll set\n"); > > pos->epoll_state &= ~MHD_EPOLL_STATE_IN_EPOLL_SET; > > } > > #endif > > if (NULL != pos->response) > > { > > MHD_destroy_response (pos->response); > > pos->response = NULL; > > } > > if (MHD_INVALID_SOCKET != pos->socket_fd) > > { > > #ifdef WINDOWS > > shutdown (pos->socket_fd, SHUT_WR); > > #endif > > if (0 != MHD_socket_close_ (pos->socket_fd)) > > * MHD_PANIC ("close failed\n");* > > } > > --- > > > > Any remedies? This suggests that there is an issue with epoll? > > <[email protected]> > > I don't see why you say that. The comment you quote justifies why we > call EPOLL_CTL_DEL in addition to close(), it doesn't explain why > close() may later return an error code here. > > You might want to first investigate what type of error close() returns > here (check 'errno'). Assuming it is a 'fd already closed', we need to > figure out which code did already close the FD (and failed to set > 'pos->socket_fd' to MHD_INVALID_SOCKET. > > Note that this could be a problem in your application logic: if your > application closes() an FD that doesn't belong to it, you would get this > error as well. If we find that this very FD was (last) closed by MHD > (and where), then we can identify and fix the cause. If you want us to > help, a testcase to reproduce this would be wonderful. Other than that, > you need to do a bit more debugging ;-). > > Regardless, based on the limited information you provided. I suspect > this is rather unlikely to be EPOLL-related, > > >
