[Top][All Lists]

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

Re: [GNUnet-developers] bdb corruption

From: Christian Grothoff
Subject: Re: [GNUnet-developers] bdb corruption
Date: Fri, 6 Aug 2004 16:18:45 +0530
User-agent: KMail/1.5

On Friday 06 Aug 2004 3:21 pm, Glenn McGrath wrote:
> I just found my gnunetd has stopped unexpectently, ending in my bdb
> database being destroyed.

Did gnunetd print some error message / segfault?  I mean, it can hardly just 

> Im logging everything, i started seeing a key deletion every few reads,
> the deletions started to increase untill it lead data corruption.

Every few *reads*?  Every few *writes* would be what I'd expect, but reads
feels wrong.  GNUnet should start removing entries from the DB once the 
size-limit is reached (at which point essentially every write would start to 
be paired up with a remove operation).

> e.g. Aug  6 18:20:00 WARNING: pIdx database corrupt (could not unlink
> 85631050944F9209AAF47C1A4914C780E34809B4 from low DB (699, 114346, 0))
> I started to have problems with session keys as well.

I can't see how those two things could be related -- except if some code (bdb 
or GNUnet) caused some memory corruption.  That's hard to tell (if you can 
reproduce this while running gnunetd on top of valgrind it might be possible 
to spot the memory corruption condition, but I doubt that this is practical 
considering that it probably takes a long time until we reach this point).

> I tried to resurect the database with 'gnunet-check -a' and got
> Aug  6 19:19:27 ERROR: Unable to open the Berkeley DB: DB_INCOMPLETE:
> Cache flush was unable to complete
> Aug  6 19:19:27  could not open database
> /var/lib/GNUnet/data/afs//content//bucket.1024.3!
> Aug  6 19:19:27 __BREAK__ at logging.c:297

I wonder if there is some function in the BDB library that we should be 
calling here to 'repair' the BDB database.  

> I was running 0.6.3a i had done a gnunet-update with 0.6.3, subsequent
> attempts said it didnt need to do anything. So maybe the problem started
> because the initial gnunet-update didnt work correctly.

No, gnunet-update had nothing to do with AFS or AFS databases (and 
definitively does not touch the BDB database).


reply via email to

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