Delphi 什么会导致系统运行。偶尔会给出错误的结果？

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

调试后我发现调用System.Move中的一个数据库组件过程偶尔会给出错误的结果

请从数据库组件中查看下面的代码，并阅读我的评论。这种不一致的行为是如何发生的？ 有人能告诉我如何找出这种不一致行为的原因吗？ 注意！我不认为这段代码有什么问题，它只是用来解释问题的“症状”。 我猜是由于我们的代码或更新的gui组件代码导致了某种内存损坏或其他问题

编辑：查看下面链接的博客帖子。看来这可能与我的问题有关。至少在我读到的时候，它证实了System.Move可能会给出错误的结果：

编辑： 很抱歉，没有尽早发布我的“解决方案”，但它来了： 当使用Delphi2007时，我的问题通过使用FastMove来解决，它取代了System.Move。 升级到Delphi2010后，我还没有遇到这个问题，我们不再使用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;

---

是否可以在不修改当前代码的情况下恢复到旧的GUI组件代码？这样，您就可以知道是您的代码还是GUI组件

另一个问题是，您是否正在使用多个线程

---

编辑：出于测试原因，我只想让您还原GUI组件。您应该将它们更新到最新版本。但我还有一次机会给你。在执行移动操作之前，是否必须尝试将缓冲区归零？请参阅实现此目的的步骤。这有帮助吗？

移动不会产生错误的结果，或者至少我从未见过它会产生错误的情况。更可能的是，缓冲区中出现了意外情况。尝试在此例程中添加对Windows.OutputDebugString的调用，以查看您在前后复制的内容。

小心-假设Char=1字节。这在D2009之前还可以，但在D2009和D2010中，字符是2个字节。Move总是使用字节。这些问题是否可能在升级到D2009或D2010后发生？

我可以确认，它有时确实会失败。我只是花了几天时间来追踪它。真不敢相信。在我们的例子中，我们有.NET 2.0，在IIS 6或IIS7下运行的网站调用Delphi 2007中编写的一些COM组件，在中等负载下，它会突然开始无法移动28个字节中的16-19个字节—有时。大多数情况下，它是有效的。在大小范围为9..31字节的移动中，很可能会引发问题

最后，我们在每个System.Move（）之后都进行了CompareMem（）检查，发现ComparewMem有时会失败——这是在堆栈上分配的两个缓冲区/数组/结构之间移动！男孩，我很惊讶

复制花了很长时间。本质上，从D2006开始的System.Move是不可靠的，因为FPU堆栈上留下了一些东西。如果FPU堆栈没有问题，一切都会好起来

上面提到的博客文章是正确的。但是，无论修复是什么，它都不会影响system.Move（），因此，如果您使用Delphi 2006或更高版本编写DLL/COM，则在某个阶段会出现问题

---

我签出了D2010，系统中的代码。移动尚未更改。在我们的例子中，我将恢复系统。移到Delphi 7版本-只需使用make文件重新编译所有系统单元。

我有同样的问题：似乎FPU堆栈并非总是通过PNG+StretchBlt正确清除？

我认为System.Move在移动之前必须清除FPU堆栈？

仅供参考（以防其他人也有同样的问题）：我们为客户升级了软件，并且在应用程序启动时锁定了整个触摸屏！窗户完全冻结了！电脑必须重新启动（关机）。花了一些时间才找出完全冻结的原因

幸运的是，我们在FastMove.LargeseMove中有一个（只有1个！）AV跟踪。 我在fastmove中禁用了SSE，问题就消失了

---

顺便说一下：触摸屏有一个VIA Nehemiah cpu和一个S3芯片组。

你真的应该包括你正在使用的Delphi版本，以及你最近是否升级了Delphi版本。它使人们更容易回答你的问题。它是Delphi2007 for Win32。此外，我们使用FastMM4。（这不是我的问题，但我认识他）我现在已经固定了我的账户，并将我所有的评论从我的“答案”转移到了答案上，并将它们变成了真实的评论。我知道这个系统。移动通常不会给出错误的结果，但这一次就我所能看到的而言是这样的。如果你看我在代码中的注释，我实际上看到了系统的正确输入。Move有时会给出错误的结果。我们使用的是Delphi 2007，所以这不是我出现问题的原因。是的，可以恢复。我本来打算试试这个，但一直没能做到。事实上，我很确定问题来自gui组件，因为当我从代码中“分离”gui时，我还没有看到问题。然而，我不想只是恢复并对它感到满意，因为我们升级组件是有原因的。但我会尝试去证实/反驳我的怀疑。很遗憾，我有几天不上班。我确认。面对同样的错误。经过数小时的调试，终于找到了系统的位置。移动并比较原始结构和复制的结构显示了差异！使用CustomMove程序进行简单测试，逐字节复制修复了错误。德尔福2007。