Hi Tim, Nice finding!
Now we need to understand why this worked in the past and now it doesn't. Also, what are the implications of removing SOCK_CLOEXEC? A few pointers here: https://stackoverflow.com/questions/22304631/what-is-the-purpose-to-set-sock-cloexec-flag-with-accept4-same-as-o-cloexec BR, Alan On Tue, Jul 1, 2025 at 11:27 AM Tim Hardisty <timhardist...@gmail.com> wrote: > The error was, indeed, the socket being opened with the SOCK_CLOEXEC > flasg set. > > PR to follow. > > On 28/06/2025 16:16, Tim Hardisty wrote: > > Actually - it might be a change last year. The socket is now opened > > like this and I assume CLOEXEC will mess up the operation of the > > executed CGI app (will investigate on Monday; not sure what socket > > mode it needs to be): > > > > hc->conn_fd = accept4(listen_fd, (struct sockaddr *)&sa, &sz, > > SOCK_CLOEXEC); > > > > On 28/06/2025 13:22, Alan C. Assis wrote: > >> Hi Tim, > >> > >> Yes, I think send() is the preferred form to work with sockets > >> because you > >> can have fine control, i.e. passing flags at forth argument > >> (MSG_DONTWAIT, > >> etc). > >> > >> If you suspect that the bug was caused by some recent modification, > >> try to > >> find a supported board that was used to test thttpd in the past and > >> test an > >> old NuttX release with it. > >> This is the approach I use to double check if something is broken in the > >> mainline. > >> > >> BR, > >> > >> Alan > >> > >> On Fri, Jun 27, 2025 at 3:39 PM Tim Hardisty <timhardist...@gmail.com> > >> wrote: > >> > >>> Is it as "simple" as thttpd should do: > >>> > >>> nwritten= send(sock_fd, buffer, totalbytesread, 0); > >>> > >>> rather than the generic: > >>> > >>> nwritten= write(sock_fd, buffer, nbytes); > >>> > >>> On 27/06/2025 18:40, Tim Hardisty wrote: > >>>> Trying to get thttpd's CGI handling working and have found that the > >>>> dup(2) calls of stdin and stdout return a file descriptor that's > >>>> already been allocated to the NET socket (via thttpd I think). > >>>> > >>>> That isn't right is it? > >>>> > >>>> I am not sure if it's a side effect of something that thttpd does > >>>> (that might have been OK in the past but is now not right) or a NuttX > >>>> bug, of a missing Kconfig setting that relates to this. > >>>> > >>>> The result is that the ultimate copying of buffered html that should > >>>> be written via the socket FD gets rejected as the FD doesn't have WR > >>>> access (and is now the wrong FD anyway!). > >>>> > >>>> Perhaps there's been a change in the way NuttX deals with all of this > >>>> that didn't get sorted in thttpd? > >>>> >
