delphi - 是什么导致System.Move偶尔给出错误的结果？

最近几天，第三方开发的数据库组件出现了一些奇怪的问题。这些组件几个月都没有任何变化。
HAS最近几天更改的代码是我们自己的代码，我们还更新了由第三方开发的gui组件。

调试后，我发现在数据库组件过程之一中对System.Move的调用有时会产生错误的结果！

请查看下面来自数据库组件的代码，并阅读我的评论。这种不一致的行为如何发生？
谁能给我一个关于如何继续寻找这种不一致行为原因的想法？
注意！我认为此代码没有任何问题，仅显示它是为了解释问题“症状”。
我的猜测是，由于我们的代码或更新的gui-component-code导致某种内存损坏或某些原因。

编辑：看看下面链接的博客文章。看来这可能与我的问题有关。至少在我阅读该书时，它确认System.Move可以给出错误的结果：
http://blog.excastle.com/2007/08/28/delphi-bug-of-the-day-fpu-stack-leak/

编辑：
很抱歉没有及早发布我的“解决方案”，但它来了：
当使用Delphi 2007时，我的问题是通过使用FastMove代替System.Move来解决的。
升级到Delphi 2010后，我还没有遇到问题，我们不再使用FastMove。

Procedure InternalDescribe;
var
  cbufl: sb4; //sb4=LongInt
  cbuf: array[0..30] of char;
  cbufp: PChar;
  //....
begin
  //..Some code
  repeat
    //...Some code to initialize cbufp and cbufl

    //On the 15. iteration the values immediately Before Move are always these:
    //cbufp = 'STDPRODUCTSTOREDELEMENTSCOUNT'
    //cbuf = ('S', 'T', 'A', 'T', 'U', 'S', #0, 'E', 'V', 'A', 'R', 'R', 'E', 'C', 'I', 'D', #0, 'D', 'U', 'C', 'T', 'I', 'D', #0, #0, #0, #0, #0, #0, #0, #0)
    //cbufl = 29

    Move(cbufp^, cbuf, cbufl);

    //Values immediately After Move should then be:
    //cbuf = ('S', 'T', 'D', 'P', 'R', 'O', 'D', 'U', 'C', 'T', 'S', 'T', 'O', 'R', 'E', 'D', 'E', 'L', 'E', 'M', 'E', 'N', 'T', 'S', 'C', 'O', 'U', 'N', 'T', #0, #0)

    //But sometimes this Move results in this value( 1 in 5..15 times):
    //cbuf = ('S', 'T', 'D', 'P', 'R', 'O', 'D', 'U', 'C', 'T', 'S', 'T', 'O', 'R', 'E', 'D', #0, #0, #0, #0, #0, 'N', 'T', 'S', 'C', 'O', 'U', 'N', 'T', #0, #0) }

  until SomeCondition;
  //...Some more code
end;

最佳答案

Move不会给出错误的结果，或者至少我从来没有见过这种情况。您更有可能在缓冲区中遇到了意外情况。尝试在此例程中添加对Windows.OutputDebugString的调用，以查看之前和之后要复制的内容。