It was an FD created with pipe() and, which was used to redirect a new
process' stdout, the uv_poll_init() is called in the parent, and the in the
child a dup2() is called to attach it to stdout or stderr, before the exec.
So:
fd = pipe()
uv_poll_init(fd)
uv_poll_start()
and then in the child:
dup2(fd,CHILD_STDOUT)
Here is how I fixed it. And I think this may be an issue in libuv... I made
an alternate version of uv_poll_init() with an alt uv_poll_check_fd() :
int ww_alt_uv__io_check_fd(uv_loop_t* loop, int fd) {
// struct uv__epoll_event e;
int rc = 0;
// see:
https://stackoverflow.com/questions/12340695/how-to-check-if-a-given-file-descriptor-stored-in-a-variable-is-still-valid
rc = fcntl(fd, F_GETFD);
if (rc == -1) {
rc = errno;
}
// e.events = POLLIN;
// e.data = -1;
//
// rc = 0;
// if (uv__epoll_ctl(loop->backend_fd, UV__EPOLL_CTL_ADD, fd, &e))
// if (errno != EEXIST)
// rc = -errno;
//
// // no abort() on failure, just report back fail
// if (rc == 0)
// if (uv__epoll_ctl(loop->backend_fd, UV__EPOLL_CTL_DEL, fd, &e))
// rc = -errno;
//
return rc;
}
https://github.com/WigWagCo/greasego/blob/master/deps/src/greaseLib/deps/libuv-v1.10.1/src/unix/linux-core.c#L169
I'm not sure how or why the check_fd code came about... I do get why the
code abort()s, b/c if you can add but not delete, the FD set for epoll is
totally messed up. But the problem with that check is you run the risk of
messing the epoll set up, and having to do an abort(). And an abort() is a
no go for us.
What's interesting is while the del FD part of the code failed in the
original, using this check above, the FD passes, and the redirect works as
expected.
-Ed
On Sunday, October 8, 2017 at 6:03:15 PM UTC-5, Saúl Ibarra Corretgé wrote:
>
>
>
> > On Oct 7, 2017, at 11:13, Ed Hemphill <[email protected] <javascript:>>
> wrote:
> >
> > I have a problem with an abort() getting called by the following code in
> linux-core.c:
> >
> >
> > int uv__io_check_fd(uv_loop_t* loop, int fd) {
> > struct uv__epoll_event e;
> > int rc;
> >
> > e.events = POLLIN;
> > e.data = -1;
> >
> > rc = 0;
> > if (uv__epoll_ctl(loop->backend_fd, UV__EPOLL_CTL_ADD, fd, &e))
> > if (errno != EEXIST)
> > rc = -errno;
> >
> > if (rc == 0)
> > if (uv__epoll_ctl(loop->backend_fd, UV__EPOLL_CTL_DEL, fd, &e))
> > abort();
> >
> > return rc;
> > }
> >
> > (gdb) frame 2
> > #2 0x000000000080d842 in uv__io_check_fd (loop=0x7ffff7dd8c40
> <libLoop>, fd=33) at ../src/unix/linux-core.c:164
> > 164 ../src/unix/linux-core.c: No such file or directory.
> > (gdb) p errno
> > $1 = 2
> >
> >
> >
> > My understanding is this code is to check whether the FD can actually be
> added to the epoll set. What I don't get, is why the abort() would ever be
> reached. I.e. why does epol_ctl() allow you to add the FD if it can't
> remove it (meaning it really could not add it)?
> >
> > I was wondering if someone could shed some light on how this code came
> about, and why an FD would be in such a state that it would reach the
> abort(). The amount knowledge on the epoll inner workings out there on the
> net is minimal.
> >
> > In my case, the errno is 2 on second epoll_ctl fail, which is ENOENT
> >
> > Thanks so much,
> > Ed
> >
> >
> >
> > more backtrace
> >
> > (gdb) bt
> > #0 0x00007ffff6c08c37 in __GI_raise (sig=sig@entry=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> > #1 0x00007ffff6c0c028 in __GI_abort () at abort.c:89
> > #2 0x000000000080d842 in uv__io_check_fd (loop=0x7ffff7dd8c40
> <libLoop>, fd=33) at ../src/unix/linux-core.c:164
> > #3 0x000000000080273c in uv_poll_init (loop=0x7ffff7dd8c40 <libLoop>,
> handle=0x1780858, fd=33) at ../src/unix/poll.c:58
> > #4 0x00007ffff7bc8715 in
> fdRedirectorTicket::fdRedirectorTicket(unsigned int, int, void
> (*)(GreaseLibError*, int, int)) ()
> > from /home/ed/work/gostuff/src/
> github.com/WigWagCo/maestro/../greasego/deps/lib/libgrease.so.1
> >
>
> What kind of fd is that?
>
> --
> Saúl
>
>
--
You received this message because you are subscribed to the Google Groups
"libuv" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/libuv.
For more options, visit https://groups.google.com/d/optout.
