Skip to content

Timeouts sometimes not fired on Linux/ARM #2326

Closed
Closed
Timeouts sometimes not fired on Linux/ARM#2326
Labels
armIssues and PRs related to the ARM architecture.timersIssues and PRs related to timers, setImmediate(), setInterval(), and setTimeout().

Description

@snorp
snorp
opened on Aug 7, 2015

I'm having a problem where long (1 hour) timeouts registered via setTimeout() are not fired if the process has been idle for a while. If I then trigger some I/O by loading a page, the past-due timeout is immediately fired. Inspecting with gdb while in this 'hung' state shows that it's sitting in epoll_pwait():

#0  syscall () at ../ports/sysdeps/unix/sysv/linux/arm/syscall.S:38
#1  0x0085c790 in uv__epoll_pwait (epfd=<optimized out>, events=events@entry=0xbec35b40, nevents=nevents@entry=1024, timeout=timeout@entry=1789569, sigmask=sigmask@entry=67108864) at ../deps/uv/src/unix/linux-syscalls.c:340
#2  0x0085b2a6 in uv__io_poll (loop=loop@entry=0xa97510 <default_loop_struct>, timeout=1789569) at ../deps/uv/src/unix/linux-core.c:235
#3  0x0085189e in uv_run (loop=0xa97510 <default_loop_struct>, mode=UV_RUN_ONCE) at ../deps/uv/src/unix/core.c:328
#4  0x008009b0 in node::Start(int, char**) ()
#5  0xb6d2f632 in __libc_start_main (main=0x26cb09 <main>, argc=2, argv=0xbec39d84, init=<optimized out>, fini=0x864999 <__libc_csu_fini>, rtld_fini=0xb6f7c4c5 <_dl_fini>, stack_end=0xbec39d84) at libc-start.c:287
#6  0x0026ccfa in _start ()

I don't know if epoll_pwait() is exceeding/ignoring the timeout or what. Will do some more digging. This is running on a BeagleBone Black under Ubuntu Trusty, kernel 3.14.

Activity

  1. snorp commented on Aug 7, 2015

    @snorp
    snorp
    on Aug 7, 2015
    Author

    I should add this was with io.js 2.4.0 and 2.5.0. I haven't been able to test 3.0.0 due to some incompatibilities with modules, but I'll try to write a small test case to use there.

  2. snorp commented on Aug 7, 2015

    @snorp
    snorp
    on Aug 7, 2015
    Author

    Maybe this is related to #2232

  3. bnoordhuis commented on Aug 7, 2015

    @bnoordhuis
    bnoordhuis
    on Aug 7, 2015
    Member

    It's probably related to libuv/libuv@d1b5008 - the timeout value is exactly max_safe_timeout from that commit.

    What happens when you lower max_safe_timeout? You can find it in deps/uv/src/unix/linux-core.c.

  4. mscdex
    added
    timersIssues and PRs related to timers, setImmediate(), setInterval(), and setTimeout().
    armIssues and PRs related to the ARM architecture.
    on Aug 7, 2015

  5. Fishrock123 commented on Aug 25, 2015

    @Fishrock123
    Fishrock123
    on Aug 25, 2015
    Contributor

    cc @snorp could you try what @bnoordhuis suggested? (You'll need to build io.js yourself to do it.)

  6. snorp commented on Aug 25, 2015

    @snorp
    snorp
    on Aug 25, 2015
    Author

    Oops, I forgot to comment here. I did build io.js myself with the suggested change, but it crashed on startup for some reason, and I haven't had time to look into it more. I did add a recurring 15 minute timeout to my app and it seemed to keep things from getting into this busted state.

  7. bnoordhuis commented on Dec 16, 2015

    @bnoordhuis
    bnoordhuis
    on Dec 16, 2015
    Member

    No follow-up, closing.

  8. bnoordhuis
    closed this as completedon Dec 16, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    armIssues and PRs related to the ARM architecture.timersIssues and PRs related to timers, setImmediate(), setInterval(), and setTimeout().

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions