内存分配断点不会停止执行
我有一段存在内存泄漏的 JNI 代码：
Detected memory leaks!
Dumping objects ->
{76} normal block at 0x277522F8, 52 bytes long.
Data: < "u' "u' "u' > F8 22 75 27 F8 22 75 27 F8 22 75 27 CD CD CD CD
Object dump complete.
因此，我在指定的内存分配编号（本例中为 76）上设置了一个断点。
_crtBreakAlloc = 76;
但应用程序永远不会停止执行，就像从未执行过分配一样。
我还在程序开始和结束时拍摄了两张内存快照，并对它们进行了比较。
（在代码开始处）：（
_CrtMemCheckpoint( &s1 );
在代码结束处）：
_CrtMemCheckpoint( &s2 );
_CrtMemState s3;
_CrtMemDifference( &s3, &s1, &s2);
_CrtMemDumpStatistics( &s3 );
结果如下：
0 bytes in 0 Free Blocks.
0 bytes in 0 Normal Blocks.
0 bytes in 0 CRT Blocks.
0 bytes in 0 Ignore Blocks.
0 bytes in 0 Client Blocks.
Largest number used: 2839 bytes.
Total allocations: 101483 bytes.
看起来一切都很好。
我不明白发生了什么事。这是误报内存泄漏吗？或者是 JVM 的 memleak？如果是的话，有办法检测到吗？
找到解决方案后添加：
我修改了静态地图的初始化，问题已经解决。 特别是，我将私有静态成员从 map 转换为 map*。问题是当你初始化一个静态变量时，它必须用一个常量来初始化。 以下是我更改静态成员声明的方式：
static const map<wstring, enumValue>* mapParamNames;
所以我的 initialize() 方法变为：
map<wstring, paramNames>* m = new map<wstring, paramNames>();
(*m)[L"detectCaptions"] = detectCaptions;
(*m)[L"insertEmptyParagraphsForBigInterlines"] = insertEmptyParagraphsForBigInterlines;
(*m)[L"fastMode"] = fastMode;
(*m)[L"predefinedTextLanguage"] = predefinedTextLanguage;
(*m)[L"detectFontSize"] = detectFontSize;
(*m)[L"saveCharacterRecognitionVariants"] = saveCharacterRecognitionVariants;
(*m)[L"detectBold"] = detectBold;
(*m)[L"saveWordRecognitionVariants"] = saveWordRecognitionVariants;
KernelParamsSetter::mapParamNames = m;
最后，我在类析构函数中插入了映射的 delete ：
delete KernelParamsSetter::mapParamNames;
希望这个对某人有用。
I have a piece of JNI code with a mem leak:
Detected memory leaks!
Dumping objects ->
{76} normal block at 0x277522F8, 52 bytes long.
Data: < "u' "u' "u' > F8 22 75 27 F8 22 75 27 F8 22 75 27 CD CD CD CD
Object dump complete.
So, I set a breakpoint ont the specified memory allocation number (76 in this case).
_crtBreakAlloc = 76;
But the application never stop execution like if that allocation was never performed.
I also took two memory snapshots at the beginnning and at the end of the program, and I compared them.
(At code beginning):
_CrtMemCheckpoint( &s1 );
(At code end):
_CrtMemCheckpoint( &s2 );
_CrtMemState s3;
_CrtMemDifference( &s3, &s1, &s2);
_CrtMemDumpStatistics( &s3 );
Here the result:
0 bytes in 0 Free Blocks.
0 bytes in 0 Normal Blocks.
0 bytes in 0 CRT Blocks.
0 bytes in 0 Ignore Blocks.
0 bytes in 0 Client Blocks.
Largest number used: 2839 bytes.
Total allocations: 101483 bytes.
It seems that all is OK.
I can't figure out what is happening. Is it a false positive mem leak? Or is a memleak of the JVM? If so, is there a way to detect it?
Added after the solution was found:
I modified the initialization of a static map and the problem has been solved.
In particular, I transformed a private static member from map to map*. The problem is that when you initialize a static, it must be initialized with a constant.
Here is how I changed the declaration of the static member:
static const map<wstring, enumValue>* mapParamNames;
So my initialize() method becomes:
map<wstring, paramNames>* m = new map<wstring, paramNames>();
(*m)[L"detectCaptions"] = detectCaptions;
(*m)[L"insertEmptyParagraphsForBigInterlines"] = insertEmptyParagraphsForBigInterlines;
(*m)[L"fastMode"] = fastMode;
(*m)[L"predefinedTextLanguage"] = predefinedTextLanguage;
(*m)[L"detectFontSize"] = detectFontSize;
(*m)[L"saveCharacterRecognitionVariants"] = saveCharacterRecognitionVariants;
(*m)[L"detectBold"] = detectBold;
(*m)[L"saveWordRecognitionVariants"] = saveWordRecognitionVariants;
KernelParamsSetter::mapParamNames = m;
Finally, I inserted the delete of the map in the class destructor:
delete KernelParamsSetter::mapParamNames;
Hope this can be useful for someone.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一种可能性是存储器分配76发生在全局变量的静态初始化期间。在这种情况下，您可能将 _crtBreakAlloc 设置得太晚而无法捕获分配。
One possibility would be that memory allocation 76 occurs during the static initialization of a global variable. In that case, you may be setting _crtBreakAlloc too late to catch the allocation.