VS2022+Qt+OpenCV Debug模式下，循环中格式转换引起的内存异常问题 debug_heap.cpp

前言

最近在使用VS2022，C++，OpenCV，Qt开发时，遇到了一个疑难杂症-在循环中执行字符串格式转换会触发内存异常，经过痛苦的排查过程，终于解决了，现将问题及解决办法分享出来。

一、问题

当在使用VS2022，C++，OpenCV，Qt联合开发时，触发了一个只有在Debug模式下才出现的断点问题，十分耽误正常的测试工作：
精简一下描述就是：在循环中执行字符串格式转换会触发内存异常。例如：

		for (int l(0); l < 16; l++)//不循环反而很少能出问题，一循环就炸了
		{
			//在循环中执行以下代码1
			QString height_str1 = QString::number(1.111, 'f', 2);
			std::string height_str_std1 = height_str1.toStdString();
			
			//或在循环中执行以下代码2
			cv::String get_c_str = cv::format("%.0d", 1);
		}

都会触发debug内存自检，停止在反编译为：int 3的位置。导致程序无法正常执行

二、报错

1.提示图片

2.提示堆栈

点击重试后，提示： 【项目执行文件名.exe】!free_dbg_nolock(void * const block, const int block_use) 行 XXX C++

3.反汇编位置

— minkernel\crts\ucrt\src\appcrt\heap\debug_heap.cpp -------------------------
00007FF7DEDEB32B pop rbp
00007FF7DEDEB32C add byte ptr [rbx+5C8C8105h],cl
00007FF7DEDEB332 add byte ptr [rbx-3F7AFD20h],al
00007FF7DEDEB338 jne free_dbg_nolock+72Ch (07FF7DEDEB45Ch)
00007FF7DEDEB33E mov rax,qword ptr [header]
00007FF7DEDEB343 cmp qword ptr [rax],0
00007FF7DEDEB347 je free_dbg_nolock+630h (07FF7DEDEB360h)
00007FF7DEDEB349 mov rax,qword ptr [header]
00007FF7DEDEB34E mov rax,qword ptr [rax]
00007FF7DEDEB351 mov rcx,qword ptr [header]
00007FF7DEDEB356 mov rcx,qword ptr [rcx+8]
00007FF7DEDEB35A mov qword ptr [rax+8],rcx
00007FF7DEDEB35E jmp free_dbg_nolock+688h (07FF7DEDEB3B8h)
00007FF7DEDEB360 mov rax,qword ptr [header]
00007FF7DEDEB365 cmp qword ptr [__acrt_last_block (07FF7DF3BC828h)],rax
00007FF7DEDEB36C je free_dbg_nolock+678h (07FF7DEDEB3A8h)
00007FF7DEDEB36E lea rax,[string L"__acrt_last_blo\x4000\0\0\0\0"… (07FF7DF28C9F0h)]
00007FF7DEDEB375 mov qword ptr [rsp+28h],rax
00007FF7DEDEB37A lea rax,[string L"%ls" (07FF7DF273288h)]
00007FF7DEDEB381 mov qword ptr [rsp+20h],rax
00007FF7DEDEB386 xor r9d,r9d
00007FF7DEDEB389 mov r8d,3DAh
00007FF7DEDEB38F lea rdx,[string L"minkernel\crts\\x4000\0\0\0\0"… (07FF7DF28BE50h)]
00007FF7DEDEB396 mov ecx,2
00007FF7DEDEB39B call _CrtDbgReportW (07FF7DE71B544h)
00007FF7DEDEB3A0 cmp eax,1
00007FF7DEDEB3A3 jne free_dbg_nolock+678h (07FF7DEDEB3A8h)
00007FF7DEDEB3A5 int 3
00007FF7DEDEB3A6 xor eax,eax
00007FF7DEDEB3A8 mov rax,qword ptr [header]
00007FF7DEDEB3AD mov rax,qword ptr [rax+8]
00007FF7DEDEB3B1 mov qword ptr [__acrt_last_block (07FF7DF3BC828h)],rax
00007FF7DEDEB3B8 mov rax,qword ptr [header]
00007FF7DEDEB3BD cmp qword ptr [rax+8],0
00007FF7DEDEB3C2 je free_dbg_nolock+6AAh (07FF7DEDEB3DAh)
00007FF7DEDEB3C4 mov rax,qword ptr [header]
00007FF7DEDEB3C9 mov rax,qword ptr [rax+8]
00007FF7DEDEB3CD mov rcx,qword ptr [header]
00007FF7DEDEB3D2 mov rcx,qword ptr [rcx]
00007FF7DEDEB3D5 mov qword ptr [rax],rcx
00007FF7DEDEB3D8 jmp free_dbg_nolock+701h (07FF7DEDEB431h)
00007FF7DEDEB3DA mov rax,qword ptr [header]
00007FF7DEDEB3DF cmp qword ptr [__acrt_first_block (07FF7DF3BC818h)],rax
00007FF7DEDEB3E6 je free_dbg_nolock+6F2h (07FF7DEDEB422h)
00007FF7DEDEB3E8 lea rax,[string L"__acrt_first_bl\x4000\0\0\0\0"… (07FF7DF28CA38h)]
00007FF7DEDEB3EF mov qword ptr [rsp+28h],rax
00007FF7DEDEB3F4 lea rax,[string L"%ls" (07FF7DF273288h)]
00007FF7DEDEB3FB mov qword ptr [rsp+20h],rax
00007FF7DEDEB400 xor r9d,r9d
00007FF7DEDEB403 mov r8d,3E4h
00007FF7DEDEB409 lea rdx,[string L"minkernel\crts\\x4000\0\0\0\0"… (07FF7DF28BE50h)]
00007FF7DEDEB410 mov ecx,2
00007FF7DEDEB415 call _CrtDbgReportW (07FF7DE71B544h)
00007FF7DEDEB41A cmp eax,1
00007FF7DEDEB41D jne free_dbg_nolock+6F2h (07FF7DEDEB422h)
00007FF7DEDEB41F int 3 ----------------------------------------停在这里

三、解决办法

也就是别用这个Qt 自带的格式转换，他会操作内存，谁知道会有啥问题
代码如下：

		for (int l(0); l < 16; l++)
		{
			//在循环中执行以下代码1 变换为
			cv::String get_c_str = cv::format("%.0d", 1);
			std::string height_str1  = QString("%1").arg(QString::number(1.111,'f',2)).toLocal8Bit().constData();
			//在循环中执行以下代码2 变换为 opencv也支持这个输入，凑合用吧
			std::string get_str = QString("%1").arg(QString::number(1)).toLocal8Bit().constData();
			const char* get_c_str = get_str.c_str();
		}

这样就行了

总结

以上为开发中的一个疑难杂症，具体原因我到现在也不清楚，希望如果有知道原因，或者有更好解决办法的同志们，分享你们的解决办法。提点一下我，到底因为啥。。。