On Tue, Jul 07, 2015 at 04:40:27PM +0200, Samuel Thibault wrote: > > It looks like there is discrepancy between ipc/ipc_object.c:660 and > > kern/rdxtree.h:94. Can you manage to get -O0 traces ? > > I'll try that.
Even with a clean trace, I have a hard time understanding how it could happen. I think the best thing we can do is get the value of node->entries[index] at the time of the assertion. If it's not NULL, the node obtained from the insertion loop should normally be non-NULL too, making the function return ERR_BUSY. But entries use the least significant bit in entry slots. The node variable (in the common insertion functions) is actually rdxtree_entry_addr(prev->entries[index]), which masks the LSB. So I guess node is actually NULL, meaning the entry should be 1. As documented above struct rdxtree_node : "This implementation assumes that all nodes and stored pointers are at least 4-byte aligned, and uses the least significant bit of entries to indicate the pointer type. This bit is set for internal nodes, and clear for stored pointers so that they can be accessed from slots without conversion". Insertion functions do check that stored pointers aren't NULL and are correctly aligned. Clearing an entry (rdxtree_node_remove) does set an entry to NULL, so the LSB should get back to 0 in all cases. I really don't see how an entry could be 1... -- Richard Braun