[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
'stop'!?
> 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).
C