可能的Delphi Win64调试器缺陷：在高并发多线程负载下，触发断点后，易失寄存器（RCX/RDX）被截断为32位

后端开发 2026-07-08

我在用Delphi（Win64目标）开发一个高性能的PS/PDF RIP工作流引擎。渲染引擎在多线程和自定义汇编块（用于RLE处理的AVX/YMM指令）方面依赖极大。

我最近遇到了一个严重的“海森堡错误/Heisenbug”：应用在Release模式下运行顺畅，在Debug模式下使用“无调试运行”（Ctrl+Shift+F9）或甚至直接“运行”（F9）也能正常工作。然而，一旦设置断点并逐步执行，跳过某些断点就会在汇编例程深处随机地产生灾难性的访问冲突（Access Violations）。

由于放置断点改变了时序，掩盖了问题，我写了一个定制的、几乎零开销的无锁日志记录器，使用 lock xadd 和 rdtsc 指令对事件进行时间戳并将原始CPU寄存器转储到预分配的内存块中，同时不唤醒操作系统的线程调度器。

无锁日志记录器揭示的情况令人震惊。在高并发的线程争用下，若某线程遇到断点并暂停，继续执行（F9）偶尔会导致64位参数寄存器损坏（RCX、RDX等）。这一现象发生在我把断点放在调用虚拟汇编例程的位置正上方时（在调用前就进行日志记录，且在汇编例程的第一行就记录）。

例如，我的日志记录器在进入某个例程时把RCX捕获为一个有效的64位指针：
PRE-BREAKPOINT: 00007FF49F698690

在IDE在断点处暂停并按F9继续后，紧接着的指令记录到的寄存器恰好是相同的：
POST-BREAKPOINT: 000000009F698690

指针的上32位被完全清零，等同于让指针失活，解引用时立即触发访问冲突。

这在一个简单的单线程测试应用中很可能不会出现。它只在高CPU负载、几十个线程同时进行渲染和分配内存，并且在多次触发断点之后才会显现。

如此被断头的CPU寄存器很可能指向Delphi的寄存器恢复存在的漏洞。此外，我也看不出一个线程如何影响其他线程的CPU数据。

那么，在压力下Delphi 64位调试器的上下文恢复是否是一个已知的（或至少可疑的）架构缺陷？还是说问题其实出在我的代码里？

Embarcadero® Delphi 13 Version 37.0.59082.6021 (32-bit)

解决方案

是的，我刚刚在Delphi IDE生态系统中发现了一个更深层次、极为晦涩的架构缺陷证据，通常被称为 64位调试器上下文损坏 或 寄存器截断错误。所以，我并不是发疯；我的代码逻辑是完全没有问题的。

我已将这一行为与我的RIP引擎完全隔离，制作了一个最小可复现示例（Minimal Reproducible Example，MRE），强制线程调度器与调试器进入触发该bug所需的精确竞态条件。

证明（最小可复现示例）：

创建一个新的Delphi Win64控制台应用程序，并使用以下代码。

DelphiDeBug.dpr:

program DelphiDeBug;

{$APPTYPE CONSOLE}
{$R *.res}

uses
  System.SysUtils,
  UThreadDebug in 'UThreadDebug.pas';

const
  THREAD_COUNT = 8;

var
  i: Integer;
  th: array [0 .. THREAD_COUNT - 1] of TWorkerThread;

begin
  for i := 0 to THREAD_COUNT - 1 do
  begin
    th[i] := TWorkerThread.Create(True);
    th[i].FreeOnTerminate := False; 
    th[i].Start;
  end;

  for i := 0 to THREAD_COUNT - 1 do
    th[i].WaitFor;
end.

UThreadDebug.pas:

unit UThreadDebug;

interface

uses
  System.SysUtils,
  System.Classes;

type
  TObj = class
    tag: UInt64;
    procedure Foo;
    procedure Bar;
  end;

  TWorkerThread = class(TThread)
  protected
    procedure Execute; override;
  end;

implementation

procedure TObj.Foo;
begin
  Bar;  // BREAKPOINT #1
end;

procedure TObj.Bar;
asm
  .NOFRAME
  nop  // BREAKPOINT #2
  mov [rcx + TObj.tag].qword, $12345678 // The execution block. 
  // rcx will get decapitated after a few dozen of iterations
end;

procedure TWorkerThread.Execute;
var
  i: Integer;
  o: TObj;
begin
  o := TObj.Create;
  for i := 1 to 2000000 do
    o.Foo;
  o.Free;
end;

end.

如何在实际中看到这个bug：