1. 29 Aug, 2017 2 commits
  2. 15 Aug, 2017 2 commits
  3. 23 Jul, 2017 4 commits
  4. 27 Jun, 2017 1 commit
  5. 16 Jun, 2017 1 commit
  6. 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
  7. 05 Apr, 2017 6 commits
  8. 03 Apr, 2017 2 commits
  9. 31 Mar, 2017 4 commits
  10. 15 Mar, 2017 4 commits
  11. 14 Mar, 2017 3 commits
  12. 24 Jan, 2017 7 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
    • Rusty Russell's avatar
      tal: make tal_len/tal_count(NULL) return 0. · 9b3f4ef6
      Rusty Russell authored
      Previously it crashed, but if you're always dealing with tal arrays,
      this is painful.
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      9b3f4ef6
  13. 19 Jan, 2017 1 commit
  14. 18 Jan, 2017 2 commits
    • David Gibson's avatar
      ccanlint: Correct default coverage tool for clang · 319dadd4
      David Gibson authored
      Currently ccanlint defaults to using "gcov" as the coverage analysis tool
      for any compiler defining __GNUC__.  That's generally correct for the
      (system default) gcc.  However, clang also defines __GNUC__ because it
      implements the GCC langauge extensions.  For clang, "gcov" is not the
      correct coverage tool (clang does use roughly the gcov format, but unless
      you're very lucky the system gcc and system clang won't use the same gcov
      versions).
      
      This changes the default coverage tool in the case of clang to the correct
      "llvm-cov gcov".
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      319dadd4
    • David Gibson's avatar
      ccanlint: Allow path to gcov to be overriden · d1827b42
      David Gibson authored
      Currently ccanlint always assumes that the coverage tool can be
      invoked under the command "gcov".
      
      However, the coverage tool generally needs to be closely matched to
      the compiler version.  So, the current behaviour won't work with
      compilers other than gcc, like clang.  It won't even work for a gcc
      version which isn't the standard system one matching gcov.
      
      To address this, allow the command for the coverage tool to be
      overridden on the ccanlint command line with a new --gcov option.  We
      also allow it to be overridden for make check with a GCOV make
      variable.
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      d1827b42