Question

我使用MS VS2010和一个名为Deleaker的插件来发现我可能错过的任何内存泄漏。它告诉我fopen_s行有2个内存泄漏，但我没有在该行的任何内容上使用new或malloc。每隔一段时间它就会发现泄漏，这个位置已经发现，所以我不认为它看错了。有什么建议吗？

备注：图片加载正常，我使用LibPNG，OPAL是我自己的DLL，图像和图像＆gt;数据在应用程序中使用此DLL释放。 / em>的

我希望我已经提供了足够的信息（而不是太多）

OPAL_API void LoadPNGImage(const char* filename, OPAL::GUI::ImageStruct *&image) { int bit_depth, color_type, interlace_type; png_structp png_ptr; png_infop info_ptr; png_uint_32 width, height; unsigned char* line; unsigned int sig_read = 0; unsigned int x, y; FILE *fp; image = (OPAL::GUI::ImageStruct*)malloc(sizeof(OPAL::GUI::ImageStruct)); memset(image, 0, sizeof(OPAL::GUI::ImageStruct)); if(fopen_s(&fp, filename, "rb")) // 2 MEMORY LEAKS DETECTED HERE (False Positive??) { image = NULL; return; } png_ptr = png_create_read_struct(PNG_LIBPNG_VER_STRING, NULL, NULL, NULL); if (png_ptr == NULL) { free(image); image = NULL; fclose(fp); return; } png_set_error_fn(png_ptr, (png_voidp) NULL, (png_error_ptr) NULL, user_warning_fn); info_ptr = png_create_info_struct(png_ptr); if (info_ptr == NULL) { free(image); image = NULL; fclose(fp); png_destroy_read_struct(&png_ptr, png_infopp_NULL, png_infopp_NULL); return; } png_init_io(png_ptr, fp); png_set_sig_bytes(png_ptr, sig_read); png_read_info(png_ptr, info_ptr); png_get_IHDR(png_ptr, info_ptr, &width, &height, &bit_depth, &color_type, &interlace_type, int_p_NULL, int_p_NULL); png_set_packing(png_ptr); image->width = width; image->height = height; image->data = (unsigned char*)malloc(sizeof(unsigned char) * 4 * image->width * image->height); memset(image->data, 0, sizeof(unsigned char) * 4 * image->width * image->height); if(!image->data) { free(image->data); free(image); image = NULL; fclose(fp); png_destroy_read_struct(&png_ptr, png_infopp_NULL, png_infopp_NULL); return; } line = (unsigned char*)malloc(width * 4); if(!line) { image = NULL; fclose(fp); png_destroy_read_struct(&png_ptr, png_infopp_NULL, png_infopp_NULL); return; } for(y = 0; y < height; y++) { png_read_row(png_ptr, (unsigned char*)line, png_bytep_NULL); for(x = 0; x < width; x++) { switch(color_type) { case PNG_COLOR_TYPE_GRAY: // Don't wanna support this mode until I need it break; case PNG_COLOR_TYPE_PALETTE: // Don't wanna support this mode until I need it break; case PNG_COLOR_TYPE_RGB: image->data[4 * ((y * width) + x) + 0] = (unsigned char)line[(3 * x) + 0]; image->data[4 * ((y * width) + x) + 1] = (unsigned char)line[(3 * x) + 1]; image->data[4 * ((y * width) + x) + 2] = (unsigned char)line[(3 * x) + 2]; image->data[4 * ((y * width) + x) + 3] = (unsigned char)255; break; case PNG_COLOR_TYPE_RGBA: image->data[(4 * ((y * width) + x)) + 0] = (unsigned char)line[(4 * x) + 0]; image->data[(4 * ((y * width) + x)) + 1] = (unsigned char)line[(4 * x) + 1]; image->data[(4 * ((y * width) + x)) + 2] = (unsigned char)line[(4 * x) + 2]; image->data[(4 * ((y * width) + x)) + 3] = (unsigned char)line[(4 * x) + 3]; break; } } } free(line); png_read_end(png_ptr, info_ptr); png_destroy_read_struct(&png_ptr, &info_ptr, png_infopp_NULL); fclose(fp); }

证明它是文件名。当它直接作为const char *
传递时，我并不认为我需要清除它
这是泄漏检测器错误标记我还是我真的需要以某种方式释放它？

函数就像这样调用：LoadPNGImage("images\\tiles00.png", tiles);

Answer 1

当fopen之类的函数进行一次分配时会发生这种情况。如果你再次打电话给fopen，你就不会有更多的泄漏。

Deleaker试图隐藏这种“已知的泄漏”，但有时仍会显示它们。

调试这种情况我看到“泄漏”来自CRT中的这段代码：

int __cdecl _mtinitlocknum (
    int locknum
    )
{
...
        if ( (pcs = _malloc_crt(sizeof(CRITICAL_SECTION))) == NULL ) { <-- HERE!
        errno = ENOMEM;
        return FALSE;
    }
...
            _locktable[locknum].lock = pcs;

此分配应在_mtdeletelocks中释放：

void __cdecl _mtdeletelocks(
    void
    )
{
...
    for ( locknum = 0 ; locknum < _TOTAL_LOCKS ; locknum++ ) {
        if ( _locktable[locknum].lock != NULL &&
             _locktable[locknum].kind != lkPrealloc )
...
            _free_crt(pcs);

_mtterm（似乎只有_mtterm！）调用_mtdeletelocks。但是根据我的意见，根本没有调用_mtterm。如果EXT使用CRT，CRT可能不是一个大漏洞。

同时如果DLL使用CRT，则在DLL_PROCESS_DETACH处理程序中调用_mtterm - 对于DLL，这样的泄漏似乎很重要（DLL可以多次加载卸载）！

Answer 2

如果fopen_s无法打开文件，则应释放image数组。该工具可能会报告泄漏，并略微关闭行号。修复很简单：

    if (fopen_s(&fp, filename, "rb")) {
        free(image);
        image = NULL;
        return;
    }

更多问题：

为什么不使用calloc代替malloc并删除对memset的调用？
为什么不测试内存分配失败？
为什么不在png_create_info_struct和类似失败的情况下以相反的构造顺序释放分配的对象？
为什么不在以后的内存分配失败的情况下销毁info_ptr？
如果无法分配line，则会发现许多错误的释放调用。
未通过png_read_row

以这种方式完成错误处理非常繁琐且容易出错。您应该使用诸如RAII之类的C ++范例，或者使用常见的错误处理点来再次检查各种对象NULL或nullptr并按顺序释放它们。

我为fopen_s收到了内存泄漏但没有任何新内容或者＆＃39; malloc＆＃39; ed

2 个答案: