Re: block_cache

Hi Salvatore,

"Salvatore Benedetto" <[email protected]> wrote:
> while trying to hunt bug #2634 I found that:
> 1 - We don't check for the correct registration of low memory handler
> in the block_cache constructor, which can fail (the registration) due 
> to luck
> of memory. I don't know how problematic is that, just wanted to
> pointed it out ;-)

That's more or less neglectable, at least it's not crucial for the 
functioning of the block cache - maybe more for the rest of the system 
:-)

> 2 - There seem to be an useless check in the 
> get_next_locked_block_cache,
> -               if (cache->deleting) {
> -                       mutex_unlock(&cache->lock);
> -                       continue;
> -               }
> 
> that's after gainig the lock of the cache. The deleting flag on the 
> other hand,
> it's only set when calling the block_cache destructor, which happens
> in case the constructor fails, in which case the block_cache is now 
> not even in the
> sCacheList (and before the mutex itself wouldn't even been 
> initiliazed), and in
> block_cache_delete, but in this case we first gain the lock of the 
> cache before
> calling the destructor. So unless I'm missing something else (which 
> might be the case)
> the check can be safely removed. ;-)

That depends on the fact if mutex_lock() will really fail upon a 
destroyed mutex.
Looking at its code, it doesn't really look likely; we might want to 
change that. Until that, this code is needed, though.

> Anyway, as for the bug itself, it's clearly due to a cache_block with 
> a NULL
> hash pointer, which at first I thought could be related to bug #2631, 
> but now
> I'm pretty sure it's not, because the lock
> of the cache is gained before using the hash pointer, and therefore 
> it
> should have crashed in mutex_lock if not correctly initialized.

It doesn't really have to crash just because the mutex is not 
initialized correctly; it just might happen (or not).

> If you have any hints please let me know! ;-)

Which hash_next() was it, btw? There are two candidates (iterating over 
the blocks, and iterating over the transactions).
But looking at the code, it doesn't look like a transaction or block 
could be removed during the iteration. IOW I dunno.

Bye,
   Axel.


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/