[trouble]
The only pattern I can see is that the corruption usually occurs when the user exits the application.
If you have AutoCommit() enabled, then that may be related - it'll commit before exit.
Can you copy away the file
The commit buffers are also memory-mapped files? In which case they couldn't be corrupted by stray writes from my application code, right?
No - commit buffers are allocated. They, and administrative info, can still be corrupted. To rule this out requires running in a separate address space, i.e. process.
Is there the possibility of exiting before writes performed in a commit are finished? The question sounds dumb to me, but I am grasping at straws because I've already tried so many things.
If writes do not finish, the last step of commit is not done, i.e. the file will not be adjusted to use the new state. Any premature exit/end/crash leaves original state intact.
I'm saying this under the assumption that there is no bug in MK. If there is, I hope we can find it and resolve it ASAP!
The only other hint I have is that the bug was never reported until I split my database into three separate storage files.
Three different files, c4_Strategy objects, and c4_Storage objects? Should be no problem.
There is no longer 100% consistency between the three, i.e. you may see one commit succeed and another fail (e.g. disk full). But none of this can damage datafiles IMO.
Another programmer is playing around with the order we perform commits and delete storage objects during the application exit, but each tweak takes about a week to confirm whether it did anything or not. This is the final release-stopping bug after a year of development.
Is it an idea to record & play back the changes to force the problem to the surface? A drastic method would be to instrument all modifying calls to write out a set of instructions, perhaps as a Python or Tcl script.
Are you using threads? Are you 100% confident of the stability of the compiler and runtime library? I'm old enough to know not to point fingers at anyone but myself, but it doesn't hurt to rule out the obvious one more time...
-jcw
_______________________________________________ metakit mailing list - [EMAIL PROTECTED] http://www.equi4.com/mailman/listinfo/metakit
