bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new hurd & gnumach packages


From: Richard Braun
Subject: Re: new hurd & gnumach packages
Date: Tue, 7 Jul 2015 16:57:27 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]