我的公司已经开始有一些客户来电，因为我们的程序在他们的系统上出现访问冲突而崩溃。
崩溃发生在我们作为应用程序的一部分发布的 SQLite 3.6.23.1 中。（我们发布了一个自定义版本，以便使用与应用程序的其余部分相同的 VC++ 库，但它是库存的 SQLite 代码。）
崩溃发生在pcache1Fetch执行时call 00000000，如 WinDbg 调用堆栈所示：
0b50e5c4 719f9fad 06fe35f0 00000000 000079ad 0x0
0b50e5d8 719f9216 058d1628 000079ad 00000001 SQLite_Interop!pcache1Fetch+0x2d [sqlite3.c @ 31530]
0b50e5f4 719fd581 000079ad 00000001 0b50e63c SQLite_Interop!sqlite3PcacheFetch+0x76 [sqlite3.c @ 30651]
0b50e61c 719fff0c 000079ad 0b50e63c 00000000 SQLite_Interop!sqlite3PagerAcquire+0x51 [sqlite3.c @ 36026]
0b50e644 71a029ba 0b50e65c 00000001 00000e00 SQLite_Interop!getAndInitPage+0x1c [sqlite3.c @ 40158]
0b50e65c 71a030f8 000079ad 0aecd680 071ce030 SQLite_Interop!moveToChild+0x2a [sqlite3.c @ 42555]
0b50e690 71a0c637 0aecd6f0 00000000 0001edbe SQLite_Interop!sqlite3BtreeMovetoUnpacked+0x378 [sqlite3.c @ 43016]
0b50e6b8 71a109ed 06fd53e0 00000000 071ce030 SQLite_Interop!sqlite3VdbeCursorMoveto+0x27 [sqlite3.c @ 50624]
0b50e824 71a0db76 071ce030 0b50e880 071ce030 SQLite_Interop!sqlite3VdbeExec+0x14fd [sqlite3.c @ 55409]
0b50e850 71a0dcb5 0b50e880 21f9b4c0 00402540 SQLite_Interop!sqlite3Step+0x116 [sqlite3.c @ 51744]
0b50e870 00629a30 071ce030 76897ff4 70f24970 SQLite_Interop!sqlite3_step+0x75 [sqlite3.c @ 51806]
C代码的相关行是：
if( createFlag==1 ) sqlite3BeginBenignMalloc();
编译器 inlines sqlite3BeginBenignMalloc，其定义为：
typedef struct BenignMallocHooks BenignMallocHooks;
static SQLITE_WSD struct BenignMallocHooks {
void (*xBenignBegin)(void);
void (*xBenignEnd)(void);
} sqlite3Hooks = { 0, 0 };
# define wsdHooksInit
# define wsdHooks sqlite3Hooks
SQLITE_PRIVATE void sqlite3BeginBenignMalloc(void){
wsdHooksInit;
if( wsdHooks.xBenignBegin ){
wsdHooks.xBenignBegin();
}
}
为此的组装是：
719f9f99 mov esi,dword ptr [esp+1Ch]
719f9f9d cmp esi,1
719f9fa0 jne SQLite_Interop!pcache1Fetch+0x2d (719f9fad)
719f9fa2 mov eax,dword ptr [SQLite_Interop!sqlite3Hooks (71a7813c)]
719f9fa7 test eax,eax
719f9fa9 je SQLite_Interop!pcache1Fetch+0x2d (719f9fad)
719f9fab call eax ; *** CRASH HERE ***
719f9fad mov ebx,dword ptr [esp+14h]
寄存器是：
eax=00000000 ebx=00000001 ecx=000013f0 edx=fffffffe esi=00000001 edi=00000000
eip=00000000 esp=0b50e5c8 ebp=000079ad iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202
如果eax是 0（它是），零标志应该由 设置test eax, eax，但它是非零的。因为零标志没有设置，je不会跳转，然后应用程序在尝试执行时崩溃call eax (00000000)。
更新：eax这里应该始终为 0，因为sqlite3Hooks.xBenignBegin在我们的代码构建中没有设置。我可以用定义重建 SQLite SQLITE_OMIT_BUILTIN_TEST，这将#define sqlite3BeginBenignMalloc()在代码中打开并完全省略此代码路径。这可能会解决问题，但感觉不像是“真正的”修复；什么会阻止它在其他代码路径中发生？
到目前为止，共同因素是所有客户都在运行“Windows 7 Home Premium 64-bit (6.1, Build 7601) Service Pack 1”并拥有以下 CPU 之一（根据 DxDiag）：
- AMD A6-3400M APU，带 Radeon(tm) 高清显卡（4 个 CPU），~1.4GHz
- AMD A8-3500M APU，带 Radeon(tm) 高清显卡（4 个 CPU），~1.5GHz
- AMD A8-3850 APU 带 Radeon(tm) 高清显卡（4 个 CPU），~2.9GHz
根据维基百科的AMD Fusion 文章，这些都是基于 K10 内核的“Llano”型号 AMD Fusion 芯片，发布于 2011 年 6 月，也就是我们第一次得到报道的时候。
最常见的客户系统是东芝 Satellite L775D，但我们也有来自 HP Pavilion dv6 & dv7 和 Gateway 系统的崩溃报告。
此崩溃可能是由 CPU 错误引起的（请参阅AMD 系列 12h 处理器的勘误表），还是我忽略了其他一些可能的解释？（根据 Raymond 的说法，这可能是超频，但奇怪的是，如果是这样的话，只有这个特定的 CPU 型号会受到影响。）
老实说，这似乎不太可能真的是 CPU 或操作系统错误，因为客户在其他应用程序中没有遇到蓝屏或崩溃。肯定有其他的、更有可能的解释——但是什么？
8 月 15 日更新：我购买了一台配备 AMD A6-3400M 处理器的东芝 L745D 笔记本电脑，并且在运行该程序时可以始终如一地重现崩溃。崩溃总是在同一条指令上；.time报告崩溃前 1m30s 到 7m 的用户时间。我在原帖中没有提及的一个事实（可能与该问题有关）是该应用程序是多线程的，并且 CPU 和 I/O 使用率都很高。该应用程序默认生成四个工作线程并发布 80+% 的 CPU 使用率（在 SQLite 代码中存在一些 I/O 和互斥锁阻塞），直到它崩溃。我将应用程序修改为仅使用两个线程，但它仍然崩溃（尽管需要更长的时间才能发生）。我现在只用一个线程运行测试，它还没有崩溃。
另请注意，这似乎并不是纯粹的 CPU 负载问题。我可以在系统上毫无错误地运行 Prime95，它会将 CPU 温度提高到 >70°C，而我的应用程序在运行时几乎不会超过 50°C。
8 月 16 日更新：稍微扰乱说明会使问题“消失”。例如，将内存负载 ( mov eax,dword ptr [SQLite_Interop!sqlite3Hooks (71a7813c)])替换为xor eax, eax可防止崩溃。修改原始 C 代码以在语句中添加额外的检查会if( createFlag==1 )更改编译代码中各种跳转的相对偏移量（以及test eax, eaxandcall eax语句的位置），并且似乎也可以防止出现问题。
到目前为止我发现的最奇怪的结果是，将jneat更改719f9fa0为两条nop指令（这样控制总是落入test eax, eax指令，无论createFlag/的值esi是多少）允许程序运行而不会崩溃。