1. 12 Sep, 2017 1 commit
  2. 04 Sep, 2017 2 commits
  3. 29 Aug, 2017 3 commits
  4. 15 Aug, 2017 2 commits
  5. 23 Jul, 2017 4 commits
  6. 27 Jun, 2017 1 commit
  7. 16 Jun, 2017 1 commit
  8. 31 May, 2017 1 commit
    • Rusty Russell's avatar
      io: fix nasty io_wake corner case. · d00c9d1b
      Rusty Russell authored
      If we're duplex and one io_always callback makes the other io_always,
      we screwed up and hit an assertion later when the conn was in the
      always list but didn't actually want to be.
      
      io_wake() uses io_always(), so this is how it happened.  Writing a
      test case for this was a bit fun, too.
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      d00c9d1b
  9. 05 Apr, 2017 6 commits
  10. 03 Apr, 2017 2 commits
  11. 31 Mar, 2017 4 commits
  12. 15 Mar, 2017 4 commits
  13. 14 Mar, 2017 3 commits
  14. 24 Jan, 2017 6 commits
    • David Gibson's avatar
      .travis.yml: Add clang builds to trusty · 1a2cc003
      David Gibson authored
      This enables clang compiler builds for the trusty Travis environment.
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      1a2cc003
    • David Gibson's avatar
      coroutine: Stack allocation · b4f0767d
      David Gibson authored
      At present, coroutine stacks must be allocated explicitly by the user,
      then initialized with coroutine_stack_init().  This adds a new
      coroutine_stack_alloc() function which allocates a stack, making life
      easier for users.  coroutine_stack_release() will automatically determine
      if the given stack was set up with _init() or alloc() and act
      accordingly.
      
      The stacks are allocate with mmap() rather than a plain malloc(), and a
      guard page is added, so an overflow of the stack should result in a
      relatively debuggable SEGV instead of random data corruption.
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      b4f0767d
    • David Gibson's avatar
      coroutine: Enable valgrind · fe3995b4
      David Gibson authored
      Currently valgrind checks are disabled on the coroutine module,
      because switching stacks tends to confuse it.  We can work around this
      by using the valgrind client interface to explicitly inform it about
      the stacks we create.
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      fe3995b4
    • David Gibson's avatar
      coroutine: Remove on-stack buffers from testcases · f6557ca6
      David Gibson authored
      In preparation for enabling valgrind tests, remove instances where we
      allocate a coroutine's stack from a buffer itself on the stack.  Not all
      that surprisingly, valgrind gets very, very confused by having one
      "thread"'s stack embedded within another's.
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      f6557ca6
    • David Gibson's avatar
      coroutine: Move total initialization outside coroutine · d24c5a01
      David Gibson authored
      The sample coroutine in api-3 initializes a total to 0, then adds up the
      pseudo-random data it has placed into a stack buffer, to ensure that the
      compiler won't elide the reading and writing of that buffer.  After the
      coroutine has completed, we verify that total is non-zero so that we'll
      detect if the coroutine failed to execute entirely.
      
      Except that the initialization of total is within the coroutine itself,
      so it could also be non-zero due to it simply being uninitialized.  This
      moves the initialization outside the coroutine, to make the test a little
      more robust.
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      d24c5a01
    • David Gibson's avatar
      coroutine: Remove problematic diagnostic from api-3 test · ace6131e
      David Gibson authored
      The api-3 testcase devotes most of its available stack space to a test
      buffer, leaving only a small amount (COROUTINE_MIN_STKSZ) for the actual
      stack usage of the coroutine.
      
      It turns out that the ccan/tap diag() function can - depending on compiler
      version and flags, and on whether diagnostics are enabled - exceed that
      limited stack space.  That leads to a stack overrun, and in turn corruption
      of the parent routine's stack, generating unpredictable and hard to debug
      SEGVs.
      
      At present, this bug seems to be tripped by clang-3.8 when diagnostic
      messages are printed.
      
      This removes the troublesome diag() call.
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      ace6131e