我遇到 fopen_s 的内存泄漏，但没有任何内容是“新的”或“malloc”的

Question

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

注意事项：图像加载正常，我使用的是 LibPNG，OPAL 是我自己的 DLL，图像和图像-> 数据在使用的应用程序中释放这个 DLL.

希望我提供了足够的信息（不要太多）

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_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

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

Answer 2

当像 fopen 这样的函数进行一次性分配时，就会发生这种情况。如果您随后再次调用 fopen，您将不会再泄漏。

Deleaker 试图隐藏此类 "known leaks" 但有时它们仍会显示。

调试这种情况我看到 "leak" 来自 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 根本没有被调用。如果CRT被一个EXE使用，可能对CRT来说不是什么大的泄漏。

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

我遇到 fopen_s 的内存泄漏，但没有任何内容是“新的”或“malloc”的

I'm getting a memory leak for fopen_s but nothing is 'new'ed or 'malloc'ed

c++

memory

memory-leaks