struct ripemd160_ctx has a union for converting between u8[] and u32[]
data.  Unfortunately the u32 array has a miscalculated size, half the size
of the u8 array.  That means some accesses which are within the union can
technically overrun the u32 array.

Found by Coverity scan.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

compile_info() can leak an open file descriptor write_all() fails.  This
corrects it.

Found by Coverity.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Somewhat ironically, a path in failtest related to detecting leaks in the
tested program itself leaks memory.  This corrects it.

Detected by Coverity.
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>

This corrects several places in ccan where stdarg.h is used but there is a
missing va_end().  You can get away with this on many platforms, but not
all.

Caught by Coverity scan.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

lbalance uses the tlist module. tlist causes compile warnings on clang if
you're not careful, because it can put 0 length arrays in the middle of
structures.  tlist2 doesn't have the problem, and also has a slightly
cleaner interface.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

tools/ccanlint/async.c uses kill(2), but doesn't include the signal.h
header it comes from.  One some platforms we get away with this via
indirect includes, but not on all.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

tools/manifest.c uses asort(), but the asort module is not in
TOOLS_CCAN_MODULES.  That causes compile failures on some platforms, so
correct it.
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>

commit 25b7406d tried to make the tests
depend on the info file, but that broke .fast.ok, which used the same
pattern:

	%.ok: $(LINT) %info

This is what happens when you're too tricky!  Simply duplicate the rule,
and change .fast.ok to .fast-ok so it doesn't match both.
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>

This is needed for emergency handling in lightningd: we want to output
a (fatal) error packet on the socket, but we don't want to do so in the middle
of another packet.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Signed-off-by: Martin Milata <martin@martinmilata.cz>

This enables clang compiler builds for the trusty Travis environment.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

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

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>