- 04 Jan, 2011 1 commit
-
-
Rusty Russell authored
-
- 01 Jan, 2011 9 commits
-
-
Rusty Russell authored
I chose not to do the "macro creates set of routines" approach, as we can be almost as safe with a struct containing a pointer to the member type.
-
Rusty Russell authored
I find hiding the declaration in LIST_HEAD() a bit weird.
-
Rusty Russell authored
In particular, we test the corruption cases.
-
Rusty Russell authored
Deletion from a specific list.
-
Rusty Russell authored
-
Rusty Russell authored
When CCAN_LIST_DEBUG was defined, we were previously calling list_check() in list_del instead of list_check_node(), which caused a warning. We also should stick within the "list_" prefix namespace, so rename "debug_list" to "list_debug".
-
Rusty Russell authored
-
Rusty Russell authored
-
Rusty Russell authored
-
- 23 Dec, 2010 4 commits
-
-
Rusty Russell authored
-
Rusty Russell authored
We lose the histograms, but this prepares it for upstream merge.
-
Rusty Russell authored
One free record is not "uncoalesced".
-
Rusty Russell authored
Remove code duplication, and allow unit tests (which #include both).
-
- 16 Dec, 2010 1 commit
-
-
Rusty Russell authored
Test compiled with warnings: /home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c:/home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c: In function ‘main’: /home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c:18:2: warning: taking address of expression of type ‘void’ /home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c:18:2: warning: taking address of expression of type ‘void’ /home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c:18:2: warning: taking address of expression of type ‘void’ /home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c:18:2: warning: taking address of expression of type ‘void’ /home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c:18:2: warning: taking address of expression of type ‘void’ /home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c:18:2: warning: taking address of expression of type ‘void’ /home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c:18:2: warning: taking address of expression of type ‘void’ /home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c:19:2: warning: taking address of expression of type ‘void’
-
- 13 Dec, 2010 4 commits
-
-
Rusty Russell authored
If they specify valgrind options in their _info, we should use them when running with --db-attach=yes, too.
-
Rusty Russell authored
This is complicated by valgrind's limited options, and our desire not to run valgrind twice (it's already the slowest part of the tests). Ideally I'd like a different error code for each kind of error. I could parse and pretty-print the XML output, but instead I just parse the human-readable (which is fragile).
-
Rusty Russell authored
-
Rusty Russell authored
It requires that we build the objects first.
-
- 08 Dec, 2010 4 commits
-
-
Rusty Russell authored
-
Ronnie Sahlberg authored
trbt_delete32() was broken and caused SEGV as soon as you tried to delete an object from a tree. Rework trbt_delete32() to instead just call talloc_free() instread of trying to call delete_node() directly. This makes the "from_destructor" argument to delete_node() redundant so that parameter is removed too. Signed-off-by:
Ronnie Sahlberg <sahlberg@lenovo-laptop.(none)>
-
Rusty Russell authored
Unfortunately, gcc only warns if it sees an unknown attribute (in this case, gcc 4.1 vs "cold").
-
Rusty Russell authored
cc -g -Wall -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -I. -MD -Werror -c -o tools/ccanlint/tests/examples_run.o tools/ccanlint/tests/examples_run.c cc1: warnings being treated as errors tools/ccanlint/tests/examples_run.c: In function ‘scan_forv’: tools/ccanlint/tests/examples_run.c:37: warning: passing argument 2 of ‘__builtin_va_copy’ discards qualifiers from pointer target type tools/ccanlint/tests/examples_run.c:43: warning: passing argument 4 of ‘scan_forv’ from incompatible pointer type tools/ccanlint/tests/examples_run.c:52: warning: passing argument 4 of ‘scan_forv’ from incompatible pointer type tools/ccanlint/tests/examples_run.c:60: warning: passing argument 4 of ‘scan_forv’ from incompatible pointer type tools/ccanlint/tests/examples_run.c: In function ‘scan_for’: tools/ccanlint/tests/examples_run.c:78: warning: passing argument 4 of ‘scan_forv’ from incompatible pointer type make: *** [tools/ccanlint/tests/examples_run.o] Error 1 It really doesn't like constifying a va_arg, so remove the const declaration.
-
- 07 Dec, 2010 1 commit
-
-
Rusty Russell authored
-
- 06 Dec, 2010 8 commits
-
-
Rusty Russell authored
Chris Cowan tracked down a SEGV in sub_alloc: idp->level can actually be equal to 7 (MAX_LEVEL) there, as it can be in sub_remove.
-
Rusty Russell authored
(Imported from SAMBA commit 2db1987f5a3a) Right-shifting signed integers in undefined; indeed it seems that on AIX with their compiler, doing a 30-bit shift on (INT_MAX-200) gives 0, not 1 as we might expect (THIS WAS WRONG, REAL FIX LATER). The obvious fix is to make id and oid unsigned: l (level count) is also logically unsigned. (Note: Samba doesn't generally get to ids > 1 billion, but ctdb does) Reported-by:
Chris Cowan <cc@us.ibm.com> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au>
-
Rusty Russell authored
(Imported from b53f8c187de8) Author: Rusty Russell <rusty@rustorp.com.au> Date: Thu Jun 10 13:27:51 2010 -0700 Since idtree assigns sequentially, it rarely reaches high numbers. But such numbers can be forced with idr_get_new_above(), and that reveals two bugs: 1) Crash in sub_remove() caused by pa array being too short. 2) Shift by more than 32 in _idr_find(), which is undefined, causing the "outside the current tree" optimization to misfire and return NULL.
-
Rusty Russell authored
This causes a SEGV on my laptop.
-
Rusty Russell authored
We insert comments when we massage or combine examples; don't let these throw off our analysis (as happened for idtree.h).
-
Rusty Russell authored
-
Rusty Russell authored
We might as well use the compiled .o rather than all the little .o files.
-
Rusty Russell authored
Out-by-one error had us using character prior to declaration, eg, in "static int *foo" we use "*foo". This seems to compile, but is weird.
-
- 03 Dec, 2010 1 commit
-
-
Rusty Russell authored
Commit da72623a added a typo; ccanlint caught it, but doesn't consider test compile failing to be fatal (it should!).
-
- 01 Dec, 2010 7 commits
-
-
Rusty Russell authored
-
Rusty Russell authored
Specifically the linked free tables, and reflect on the status of each point of the design document.
-
Rusty Russell authored
Rather than overloading TDB_USED_MAGIC and the hash value as we do now. We also rename "free list" to the more-accurate "free table" everywhere.
-
Rusty Russell authored
Currently we fall back to copying data during a transaction, but we don't need to in many cases. Grant direct access in those cases. Before: $ ./speed --transaction 1000000 Adding 1000000 records: 2409 ns (59916680 bytes) Finding 1000000 records: 1156 ns (59916680 bytes) Missing 1000000 records: 604 ns (59916680 bytes) Missing 1000000 records: 604 ns (59916680 bytes) Traversing 1000000 records: 1226 ns (59916680 bytes) Deleting 1000000 records: 1556 ns (119361928 bytes) Re-adding 1000000 records: 2326 ns (119361928 bytes) Appending 1000000 records: 3269 ns (246656880 bytes) Churning 1000000 records: 5613 ns (338235248 bytes) After: $ ./speed --transaction 1000000 Adding 1000000 records: 1902 ns (59916680 bytes) Finding 1000000 records: 1032 ns (59916680 bytes) Missing 1000000 records: 606 ns (59916680 bytes) Missing 1000000 records: 606 ns (59916680 bytes) Traversing 1000000 records: 741 ns (59916680 bytes) Deleting 1000000 records: 1347 ns (119361928 bytes) Re-adding 1000000 records: 1727 ns (119361928 bytes) Appending 1000000 records: 2561 ns (246656880 bytes) Churning 1000000 records: 4403 ns (338235248 bytes)
-
Rusty Russell authored
This is a precursor to direct access during transactions: they care about whether we are going to read or write to the file.
-
Rusty Russell authored
If we get enough hash collisions, we can run out of hash bits; this almost certainly is caused by a deliberate attempt to break the tdb (hash bombing). Implement chained records for this case; they're slow but will keep the rest of the database functioning.
-
Rusty Russell authored
We have to unlock during coalescing, so we mark records specially to indicate to tdb_check that they're not on any list, and to prevent other coalescers from grabbing them. Use a special free list number, rather than a new magic.
-