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

Reply via email to