summaryrefslogtreecommitdiff
path: root/bugs/crashing-early-leads-to-assertion-error.mdwn
blob: bda5d1189d76a32b1b2b0b28f8e6c4e9d257d2c9 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
> `<SLi> liw, I run obnam backup for a small while (probably not
> until even the first checkpoint) on a new repository, then ctrl-c
> and say obnam fsck, I get AssertionError on assert 'key_size' in
> ns_temp.get_metadata_keys().`

Two things:

* using `assert` is wrong in the code, it should raise an exception that
  results in a humane error message
* crashing before the first checkpoint should not result in an error
  in the first place

--liw

I've fixed the assertion in larch (it's now a more user-friendly
error message). The crash still occurs, but I'm not sure if it's
reasonable for Obnam to try to correct that. The same error may
happen due to other reasons, and automatically fixing things is
too likely to break things. So I'll leave the bug open, but take
it off the 1.0 blockers list.

--liw

I can reproduce this, by instrumenting the code so that
it crashes after having backed up the first file. The error printed
correctly identifies that the B-tree is broken. However, it is
broken in a useful way. The B-tree is going to be so broken it
does not have much useful information. There are some things that
could be done (e.g., if no key size is stored in the B-tree, add
one), but that only helps in specific cases, and I don't think
that's useful enough. Thus, I think I will just give up for this
kind of early corruption and have people start over. Sorry.
(I'd fix this if I had lots of extra time, but I don't. If someone
comes upon this bug later on, and makes a good patch, I'd be
happy to accept it, of course.)

--liw

[[done]]