On Tue, Sep 23, 2014 at 10:49 AM, Jan Flyborg jan.pers...@gmail.com [firebird-support] <firebird-support@yahoogroups.com> wrote:
> > > The first was a wrong page type, which sounds like a bug that was fixed in >> a newer version in code that's common to all Firebird architectures. In >> your case, the bad page was in an index (7). If you can find the index >> with the bad page and recreate it, all will be well. >> >> That sounds very good and it seems like an upgrade to 2.5.3 will make > sure that we do not see this again. > Anytime your users get an error of of the form "wrong page type, expected 7 encountered n", you can probably work with them to identify and rebuild the bad index. > > >> >> The second problem (CCH_precedence: block marked. file: cch.cpp line: >> 4390) is more concerning >> > If that is of any help for you, I was wrong in my original posting when I > said we were using 2.5.1 (I mean that the line numbers in the exception > might lead you to draw the wrong conclusion when I gave you the wrong > version). We are currently using 2.5.2 and nothing else. > I follow bug reports but not religiously. So I searched for one that includes "block marked" and "modify RDB$INDICES" and found #4467 which is marked as "will not fix" and described as a user error. User errors should not cause internal cache manager problems, so I'm somewhat bemused. It was reported in 2.5.2, so it may well be your problem. > > > >> The third problem is two records in a referencing table lack mates in the >> referenced table, despite a referential constraint. I have no idea how >> that happened, but it should be reasonably easy to fix in your database. >> > > In another posting (later than yours) Fabiano is saying that these errors > are connected to bad memory chips and in the future we will instruct our > users who are having this problem to run memtest86 overnight to check that > the memory is physically OK. These constraints problems are actually the > most common that we see. > Clever memory problem to corrupt just the key or the constraint check. Certainly it's worth checking that the memory is OK. I'd also check that the referencing key looks generally sound. Do you add referential constraints to existing databases? A problem with broken constraints is that the error doesn't leave traces, so a reproducible case would be very helpful, but very hard to produce. > > >> >> Gfix is pretty old and somewhat crude. IBFirstAid might give you better >> help on physical corruptions. Checking that there is no non-conforming >> data before creating constraints may help with logical corruption. >> > > Yes that would probably be a better choice for us, but we cannot bundle > IBFirstAId togethe r with our application. Will however download it and > try it on files to got sent to us. > The analysis tool is free - maybe your users could download it themselves to look for evidence. But it's not going to help with broken referential constraints or mangled cache precedence. > > > Another thing, what do you say about the posting above where the theory is > that Volume Shadow Copy is interfering with the database? Have you heard > about that before? > I'm quite sure that Volume Shadow Copy won't make good copies of an active database or any other file that's open for random writes. Whether it could corrupt the original is an open question. Lots of people claim to have seen instances where copying a database corrupts the original. > > And another last comment. We have bundled Firebird w ith very many > installations of our product and it might be the case that what we are > seeing are very rare problems, that no one else has experienced before. Do > you think we should post bug reports every time we see an exception or a > problem that you have not already been made aware of? > Search the tracker (http://tracker.firebirdsql.org/browse) first to see if the problem has been reported. Then you might mention it on the support list to see if there's something that looks like a user error so you won't annoy the developers with stuff that the volunteers on this list could resolve. But if your getting errors with source file and line numbers, the chances are good that you've found a bug. Firebird is used pretty widely and quite heavily in many installations. However, the embedded form probably gets less stress in the world than any of the architectures, so you may be stressing something unusual. No development group, open or closed source, can fix bugs it doesn't know about. Thank you for working with Firebird on these problems. Good luck, Ann
