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: David Gibson <david@gibson.dropbear.id.au>

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: David Gibson <david@gibson.dropbear.id.au>

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: David Gibson <david@gibson.dropbear.id.au>

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: David Gibson <david@gibson.dropbear.id.au>

Previously it crashed, but if you're always dealing with tal arrays,
this is painful.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Now that we have a way to correctly set a matching coverage tool, we can
add more recent compiler versions to the Travis build.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

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: David Gibson <david@gibson.dropbear.id.au>

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: David Gibson <david@gibson.dropbear.id.au>

At the moment, invocation of the 'gcov' tool for coverage analysis
from ccanlint is put directly into the tests_compile_coverage.c and
tests_coverage.c files.  This makes it awkard to extend.

So, this patch moves the invocation of gcov into a new tools/gcov.v
file, analagous to tools/compile.c.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Currently, our Travis builds don't have valgrind installed, meaning
that ccanlint's valgrind based tests will be skipped, which is
unfortunate.

This adds valgrind to some of the builds to give us better CI
coverage.  It's not added for Precise with gcc, because that causes
failures which appear to be due to something in the builtins of that
gcc version.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

At the moment our Travis builds all use Travis's default Ubuntu
Precise base distro.  For wider testing, add a build using their
Ubuntu Trusty distro.  Only build with gcc there, for now, since clang
will cause ccanlint failures, due to the gcov version there not being
suitable for clang output.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

At the moment the .travis.yml implicitly constructs a build matrix
with the two compiler options.  In future we want to add more build
options for wider testing: different base distro, more compiler
versions, etc.  However, a fair few of the possible combinations have
various problems meaning we don't want to test them routinely.

So, this reworks from implicitly constructing the matrix to using
matrix: include: options to explicitly build the options we want.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

By returning the value, we have a nice sentinal and we save a second lookup
if they want it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Critbit tree to map ints/uints to pointers.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

This is what users want, and expect: as demonstrated by the test failure
when not under valgrind!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

While investigating the previous patch, a bug caused poll to return
POLLHUP on the listening socket, which caused us to spin.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

We were closing before calling del_fd, which also closed.

The shutdown() logic applies when a child and parent are using the
*same* socket fd to communicate to each other.  That's really unusual
(who would you connect to?), and should probably be done by the user.

Generally, you'd use socketpair() for this child-parent case.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Helps with the common case of wanting to NULL out a pointer when the object
freed.  We could also track it if resized, but that's TODO.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

There are several times I've wanted an extra arg to the destructor, and had
to embed it in the thing destroyed.  It's more efficient to put it into
tal itself (since it allocates space anyway), but we make it conditional
on a flag to avoid bloating every destructor.

The infrastructure makes it easier to add an extra arg to the general
notifiers later if we want.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

io_close() currently marks the io_conn for freeing, but doesn't
actually do it.  This is a problem for tal() users, because we can't
just call it in the parent's constructor.

Make io_close() just tal_free() + return &io_conn_freed (a magic
io_plan pointer).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

It seemed like a good idea, but it complicates things and I never used
it (since I never really trusted that the alternate paths would be
equivalent).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

So the errno when you call tal_free() is handed to all the notifiers,
independent of what the others do.

This makes sense, but also helps for the upcoming ccan/io change.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Currently, _info files can specify options, or note expected failures, for
ccanlint checks in the _info file with specially structured comments. That
differs from most other things ccanlint gets from _info, where it instead
executes the info file with certain parameters.

This changes ccanlint and existing _info files to use the normal method for
the ccanlint test options as well.  This also has the advantage that an
info file can alter its test options based on things from config.h - in
some cases whether a test can work or not might depend on various things.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Changing the _info file can change how ccanlint assesses the module.
Therefore, if the _info file changes, we should re-run ccanlint module
tests with make check.  We didn't previously have a dependency for that,
though, so this adds it.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Two copies of this map meant only the tests would ever work.

Use the new coroutine module to abstract away our dependence on
ucontext.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

This is essentially a wrapper around ucontext.h, but the idea is that
alternative back end implementations could be used in future.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

lightning uses 48 bits, so this provides a quick utility for our test
vectors, and provides a nice example.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Making arbitrary bytes a uchar* is always a bit nasty for the caller.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

The new Makefile system, via the helper script in tools/gen_deps.sh, when
generating the targets to test a module, inserts dependencies meaning it
must first check modules this one depends on, whether via 'depends' or
'testdepends' in _info.

Although it seems logical, including 'testdepends' is actually incorrect.
If ccan/a testepends on ccan/b then ccan/b must be *built* in order to test
ccan/a, but it doesn't need to be tested.  testepends are explicitly
permitted to contain loops - it's quite common for two complementary
modules to be used to test each other.  This is one of the reasons
testdepends exists separate from depends.

So, remove testdepends from the generated check dependencies, removing the
circular dependency that Make complains about.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

The previous name was misleading, since it does not define the number of
elements (ed_elem) on the stack, but rather the number of distance
values (ed_dist).  Rename to make this more clear and add more
documentation about what it does and how best to define it.

Note:  This is an API change for custom-compiled versions, but since the
module has only been included for a couple days I don't think it's worth
a back-compat #ifdef at this point.
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>

Currently Travis builds fail on the edit_distance module, because that
module uses C99 extensions, which aren't enabled by default on the
Ubuntu Precise compiler version.  Force it to allow these, by adding the
-std=gnu99 option to the compiler.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>