On further inspection I noticed that it happened when accessing random
articles which could be fetched from any time period, including the
very beginning when corruptions could have arisen. At first I thought
it was new but that does not have to be the case.

I wiped everything and switched to 64bit, clean slate.

How would it be possible to walk through all relations in all classes
and delete objects referencing missing objects without breaking in the
process?

Or better yet, simply ignore and return NIL instead of the missing
referenced object, to make things more forgiving?

All applications have different requirements, for most it might be a
good feature to simply crash the whole thing but in the case of
vizreader it doesn't really matter if a tagged article is missing from
that tag or some such.


On Sat, Nov 19, 2011 at 8:26 PM, Alexander Burger <a...@software-lab.de> wrote:
> Hi Henrik,
>
>> # ./p projects/rss-reader/main.l -go
>> !? (val Node)
>> {I-4FSO} -- Bad ID
>
> This is definitely a corrupt database. Some index tree refers to an
> object {I-4FSO}, but this is no legal object. Either it is deleted, or
> it is not a header block (i.e. the ID points to some other node in the
> block chain of an object).
>
>> ? (print val)
>> 67300608-> 67300608
>
> This is the function 'val'.
>
>
>> ? (print V)
>> ({I-4FSO} (2184837 {I-4FSN} . {3-4Sva}) (2184819 {I-4FYm} . {3-4Svu})
>> (2184801 {I-4FZg} . {3-4Swt}) (2184783 {I-4FaG} . {3-4Sx;}) (2184765
>> {I-4Fag} . {3-4SxR}) (2184747 {I-4Fbj} . {3-4T3r}) (2184729 {I-4Few} .
>> {3-4T4:}) (2184711 {I-4G6p} . {3-4T4Q}) (2184693 {I-4G7E} . {3-4TB1})
>> (2184675 {I-4G7w} . {3-4TBI}) (2184657 {I-4G8i} . {3-4TBa}) (2184639
>> {I-4GFu} . {3-4TBs}) (2184621 {I-4GG6} . {3-4TC:}) (2184603 {I-4GGn} .
>> {3-4TCh}) (2184585 {I-4Gti} . {3-4TCz}) (2184567 {I-4Gu0} . {3-4TDF})
>> (2184549 {I-4Gua} . {3-4TDX}))-> ({I-4FSO} (2184837 {I-4FSN} .
>> {3-4Sva}) (2184819 {I-4FYm} . {3-4Svu}) (2184801 {I-4FZg} . {3-4Swt})
>> (2184783 {I-4FaG} . {3-4Sx;}) (2184765 {I-4Fag} . {3-4SxR}) (2184747
>> {I-4Fbj} . {3-4T3r}) (2184729 {I-4Few} . {3-4T4:}) (2184711 {I-4G6p} .
>> {3-4T4Q}) (2184693 {I-4G7E} . {3-4TB1}) (2184675 {I-4G7w} . {3-4TBI})
>> (2184657 {I-4G8i} . {3-4TBa}) (2184639 {I-4GFu} . {3-4TBs}) (2184621
>> {I-4GG6} . {3-4TC:}) (2184603 {I-4GGn} . {3-4TCh}) (2184585 {I-4Gti} .
>> {3-4TCz}) (2184567 {I-4Gu0} . {3-4TDF}) (2184549 {I-4Gua} . {3-4TDX}))
>
> This is the node of a btree, with pointers to many objects.
>
>
>> Seems like we're somewhere in btree.l but I don't know exactly where.
>
> Yes. It can be any place that needs to access that object.
>
>
>> What I don't understand is how a database that has been humming along
>> for over 2 years without any problems suddenly breaks like this?
>
> We had that discussion about your corrupted database here already some
> time ago. IIRC, you had noticed problems when migrating that DB to
> 64-bits, probably resulting from early experiments and crashes.
>
> In fact, as long as the DB is not checked, such a corruption may stay
> unrecognized for quite some time, if the dangling ID is not accessed, or
> the block is reused by some other object due to possible corruptions in
> other places.
>
> It can be repaired manually, for example with 'edit' on the nodes of the
> tree, and repeated use of 'dbck' and 'dbCheck'. However, this may be a
> very tedious procedure, especially if that corruption caused further
> corruptions over the time. You'd better have fixed the problems at a
> time as early as possible ;-)
>
> Cheers,
> - Alex
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to