0

我知道我的问题是多维的，我可能会得到一些独立的建议，但非常感谢你所做的一切，如果这是一个新手问题，我很抱歉。

我在 Delphi RAD 10 中使用 CEF (TChromium) 浏览器。我经常在客户的生产中收到一个错误，在调试器上工作时我无法复制。显示基本Win错误信息后，系统（Win7）杀死程序，以未保存的先前工作结束。我一步步检查了代码的每个元素，请程序员同行分析，似乎这个错误只适用于CEF浏览器。每次，无论我在程序的工作中能注意到什么，错误都是一样的：

Problem signature:
  Problem Event Name:   APPCRASH
  Application Name: MyApp.exe
  Application version:  0.0.0.0
  Application timestamp:    5e36d888
  Module name with error:   libcef.dll
  Module version with error:    3.2454.1344.0
  Module timestamp with error:  562d8f27
  Exception Code:   c0000005
  Exception Offset: 001dea9b
  OS Version:   6.1.7601.2.1.0.256.1
  Locale ID:    1045
  Additional information 1: 0a9e
  Additional information 2: 0a9e372d3b4ad19135b953a78882e789
  Additional information 3: 0a9e
  Additional information 4: 0a9e372d3b4ad19135b953a78882e789

是的，我猜这个问题可能是由很多不同的东西引起的，但我假设因为这只发生在使用浏览器时（否则程序可以完美运行），并且每次显示相同的问题时，它可能是 TChromium组件。

不幸的是，我无法理解究竟是什么导致了这个问题（libcef.dll c0000005 / 001dea9b exeption），并且在各种论坛上找到的所有线程都被终止和/或未解决。

我尝试通过显示更大的消息而不是关闭程序来对每个页面加载进行编程：

procedure LoadUrl(url: String);
begin
  try
  Form1.Chromium1.Load(url);
  except
    on E : Exception do
      ShowMessage('CEF: '+E.ClassName+' error raised, with message : '+E.Message);
  end;
end;

但是在调试器上工作时（再次）我没有收到任何错误，并且在生产系统上只是杀死了应用程序而没有任何错误消息。

乍一看，我想我需要一个解释：

  • TChromium 组件实际上只有在我用“加载（url）”调用它时才会改变，所以我是否正确理解代码中的这个位置是我应该关注的地方？
  • 我可以这样编程外部库的错误/异常吗？或者也许有其他方法可以安全地使用它们，这样错误就不会成为杀死应用程序的原因，而是会在生产上得到控制？
  • 上面提到的调用 TChromium 组件的过程是否会给我比杀死我的应用程序的系统更多的信息？（当然，如果这是错误的地方，因为这似乎是最稳妥的一击）
  • 我使用 EurekaLog7 工具 - 但我不明白我应该如何使用它来跟踪浏览器库错误跟踪以及在哪里调用它，甚至如何在代码中使用它。实际上，我完全不知道从哪里开始在外部库上使用它，我很乐意接受一些文档或关于阅读内容以及在哪里可以找到可以理解的示例的提示。

提前感谢您，如果这太容易或问题很愚蠢，我深表歉意。当然，我也知道，由于我没有提供完整的代码，所以分析问题会很困难，但是我想自己学习这种错误分析，所以也许你会原谅我。:)

~~补充资料

  • 程序得到x32结构，在win 7 xs64下运行；
  • 程序是一个简单的爬虫，其任务是将搜索页面的选定元素保存到文本文件形式；
  • 可选：对我来说已经足够了，如果这个错误成功触发了我自己的关闭程序，允许简单地保存结果，应用程序可以在之后被杀死，因为调度程序会复活它；
4

1 回答 1

0

感谢@J ...我想我想通了，这是解决方案。

指示的错误仅来自 libcef.dll 库的“工作”，（不幸的是）可能不再受支持。虽然这不是一个在任何地方都能解决的问题——在各种论坛中出现这个错误的大多数迹象都是在内存中引用错误地址的问题时出现的，然后按照这个线索基本上是关于各种版本中的内存不足错误。

libcef 库有一些致命的内存分配方式，它本身会导致持续的内存泄漏。这些泄漏和错误分配很快导致几乎所有可用内存的使用......而且很容易遇到类似的问题。首先，添加一个指令

{$SetPEFlags IMAGE_FILE_LARGE_ADDRESS_AWARE}

后

uses WinApi.Windows

到 dpr 形式暂时解决了问题，因为程序有更多的可用内存并且需要更长的时间来耗尽资源。当然，这并没有结束问题，因为该计划的暂停只会花费更长的时间。

但！每隔几十次扫描（爬取）一次就会为表单重新分配内存，这将自动分配内存，消除泄漏 - 就 libcef 库而言也是如此。我发现并使用了不时调用的此类代码。对我来说，每 20 次浏览器转一次就足够了，但对每个人来说可能看起来都不一样。您需要尝试触发。

 procedure TrimAppMemorySize;
 var
   MainHandle : THandle;
 begin
   try
     MainHandle := OpenProcess(PROCESS_ALL_ACCESS, false, GetCurrentProcessID) ;
     SetProcessWorkingSetSize(MainHandle, $FFFFFFFF, $FFFFFFFF) ;
     CloseHandle(MainHandle) ;
   except
    on E : Exception do
     // inform me about problem 
   end;
   Application.ProcessMessages;
 end;

这可能不是最好的解决方案，但它使 CEF3 的不稳定形式变得稳定并准备好工作。这几天，在同一个表格的几个副本上工作，根本没有出现任何错误，所以它可能是一个很好的解决方案，也许对于每个有CEF3内存泄漏，有类似我的未知错误，或者由于内存错误引起的CEF3。

但是 - 我的问题是如何调试 libcef.dll 以及如何获取有关 CEF3 库错误的更多信息 - 而 J... 已经完成了这个话题，非常感谢。

至于 SalvadorDíazFau 的提议 - 我非常感谢您参与该项目，像您这样的人是我们社区的基础；然而，虽然 CEF3 仍在工作，但对我来说，这比发现 CEF4 的新元素和可能性要少，因为这需要我重建表格。会有时间的。:)

感谢你们！案子已经结案了！

于 2020-02-10T17:59:05.193 回答