- 31 Mar, 2017 1 commit
-
-
David Gibson authored
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>
-
- 15 Mar, 2017 4 commits
-
-
Rusty Russell authored
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
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>
-
Rusty Russell authored
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
- 14 Mar, 2017 3 commits
-
-
Rusty Russell authored
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
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>
-
Martin Milata authored
Signed-off-by: Martin Milata <martin@martinmilata.cz>
-
- 24 Jan, 2017 7 commits
-
-
David Gibson authored
This enables clang compiler builds for the trusty Travis environment. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
-
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: David Gibson <david@gibson.dropbear.id.au>
-
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: David Gibson <david@gibson.dropbear.id.au>
-
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: David Gibson <david@gibson.dropbear.id.au>
-
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: David Gibson <david@gibson.dropbear.id.au>
-
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: David Gibson <david@gibson.dropbear.id.au>
-
Rusty Russell authored
Previously it crashed, but if you're always dealing with tal arrays, this is painful. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
- 19 Jan, 2017 1 commit
-
-
David Gibson authored
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>
-
- 18 Jan, 2017 3 commits
-
-
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: David Gibson <david@gibson.dropbear.id.au>
-
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: David Gibson <david@gibson.dropbear.id.au>
-
David Gibson authored
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>
-
- 17 Jan, 2017 3 commits
-
-
David Gibson authored
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>
-
David Gibson authored
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>
-
David Gibson authored
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>
-
- 13 Jan, 2017 1 commit
-
-
Rusty Russell authored
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>
-
- 11 Jan, 2017 1 commit
-
-
Rusty Russell authored
Critbit tree to map ints/uints to pointers. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
- 09 Jan, 2017 5 commits
-
-
Rusty Russell authored
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>
-
Rusty Russell authored
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>
-
Rusty Russell authored
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
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>
-
Rusty Russell authored
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
- 07 Jan, 2017 1 commit
-
-
Rusty Russell authored
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
- 29 Dec, 2016 5 commits
-
-
Rusty Russell authored
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>
-
Rusty Russell authored
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>
-
Rusty Russell authored
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>
-
Rusty Russell authored
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>
-
Rusty Russell authored
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>
-
- 24 Dec, 2016 2 commits
-
-
David Gibson authored
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>
-
David Gibson authored
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>
-
- 23 Dec, 2016 1 commit
-
-
Rusty Russell authored
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
-
- 12 Dec, 2016 2 commits
-
-
Peter Barker authored
Two copies of this map meant only the tests would ever work.
-
David Gibson authored
Use the new coroutine module to abstract away our dependence on ucontext. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
-