Bug when Group 0 header contains "FF"? (AREV Specific)
At 14 DEC 2005 02:12:14AM David Blythe wrote:
In the following link,
http://www.revelation.com/__85256DB80017688B.nsf/0/181C8B16C8937F8E85256B27004095DD?OpenDocument
the author discusses his finding that when a file's header in group 0 contains hex FF (in his example it was in the Alpha value), a subsequent call to the filing system's CLEARSELECT function corrupts the Alpha value.
We've had cases where our users (with OI 2.61) have experienced corrupted alpha values that led to collapse of a table into one group, often resulting in "String space format error". To date, we had thought this was a corruption due to external events, but the above topic suggests it might be a bug.
Can anyone confirm that the bug does or doesn't exist? If it does, is it explained completely somewhere? Does it occur with non-network drivers?
At 16 DEC 2005 10:28AM Hippo wrote:
Thanks for reopening the topic :)
At 16 DEC 2005 11:48AM Victor Engel wrote:
Hippo,
What did you discover following that previous thread?
Victor
At 16 DEC 2005 06:48PM Hippo wrote:
That during PERFORM "SELECT" (non using btree)
the internal loop built from subsequent READNEXT calls to MFS computes correct value of alpha, but sometimes when the operation ends (CLEARSELECT call to MFS) the computed value is not correctly passed. Therefore the MFS sets the alpha value inproperly in that case. This can start shrinking of .lk portion of the table until it consists of just one group … it can make standard access to the file is impossible as the total key length per the group exceeds 64KKB limit.
The bug is in between the end of the READNEXT loop and CLEARSELCT call (all hidden in one PERFORM "SELECT").
At 19 DEC 2005 10:49AM Victor Engel wrote:
The ALPHA is recomputed with each non-indexed select, right? So if I'm following what your saying is happening, this is only an issue of enough accesses happen between when the problem first starts until the next time a select is performed. So databases where a select is done frequently may never encounter this bug. Correct?
At 19 DEC 2005 11:33AM Hippo wrote:
I am not sure … it seemed to me that the table was in the state several selects in the row ended with the same problem (alpha updated improperly). I have created the MFS guard … mentioned in the original thread. I didn't study how often the guard had to work, but it solved the problem (the guards were not removed yet).
The process causing problem started with PERFORM "SELECT", than the read of all records (no writes). The shrinking of the table was very fast as each access (read) shrinkes one group (I suppose).
The table was in correct state before readall process starts and it was in one group state when the process ends.
So I am not sure the often used selects is a solution.
At 19 DEC 2005 11:51AM Hippo wrote:
When I was experimenting with READNEXTING loop, it seemed that the FMC logic depend on driver. So one of my suspects was there.
But in all cases it seems to me the CLEARSELECT should use the value returned by last READNEXT. So the problem is not with drivers but PROBLEM IS WITH KERNEL.
This was the problem which forces me to take part on this on-line discussion - unfortunately never satisfactory answered.