写出libjpeg图像时发生内存泄漏

Question

我正在使用一个自制的C++框架进行工作，其中一个类间接地与libjpeg-8c.so（作为Ubuntu 16.04 synaptic软件包获得）进行接口。 我在我的应用程序上运行valgrind，并最终将图像数据写出，如下所示：

        ImageDescriptor* pOutputImageDesc, int outputQuality)
{
   //set up JPEG lib context
    /* Step 4: Start compressor
     * true ensures that we will write a complete interchange-JPEG file.
     * Pass true unless you are very sure of what you're doing.
     */
    jpeg_start_compress(&cInfo, TRUE);

    /* Step 5: while (scan lines remain to be written)
     *           jpeg_write_scanlines(...);

     * Here we use the library's state variable cInfo.next_scanline as the
     * loop counter, so that we don't have to keep track ourselves.
     * To keep things simple, we pass one scanline per call; you can pass
     * more if you wish, though.
     */

    rowStride = pInputImageDesc->width * pInputImageDesc->channels; // JSAMPLEs per row in image_buffer

    while (cInfo.next_scanline < cInfo.image_height)
    {
        /* jpeg_write_scanlines expects an array of pointers to scanlines.
         * Here the array is only one element long, but you could pass
         * more than one scanline at a time if that's more convenient.
         */
        rowPointerArray[0] = &inputBuffer[(cInfo.next_scanline * (rowStride))];
        static_cast<void>(jpeg_write_scanlines(&cInfo, rowPointerArray, 1));
    }

    // Step 6: Finish compression
    jpeg_finish_compress(&cInfo);

    //setup external image context

    // Step 7: release JPEG compression object
    // This is an important step since it will release a good deal of memory.
    jpeg_destroy_compress(&cInfo);

    return 0;
}

与评论所说的相反，不是所有堆内存都被释放。在这个malloc()跟踪中，Valgrind持有不同的看法。

注意：下面的跟踪是在连接libjpeg-8d源代码后得到的。

==6025==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6025==    by 0x4E4CDCE: empty_mem_output_buffer (jdatadst.c:131)
==6025==    by 0x4E4373E: dump_buffer_s (jchuff.c:274)
==6025==    by 0x4E4373E: emit_bits_s (jchuff.c:329)
==6025==    by 0x4E4373E: encode_one_block (jchuff.c:990)
==6025==    by 0x4E4373E: encode_mcu_huff (jchuff.c:1040)
==6025==    by 0x4E40DAB: compress_data (jccoefct.c:208)
==6025==    by 0x4E45B3F: process_data_simple_main (jcmainct.c:135)
==6025==    by 0x4E3EEE3: jpeg_write_scanlines (jcapistd.c:108)
==6025==    by 0x40DC4E: CompressRawToJpg(ImageDescriptor*, ImageDescriptor*, int) (ImageCaptureHelper.cpp:646)
==6025==    by 0x40DFB2: WriteJpgImage(char*, ImageDescriptor*) (ImageCaptureHelper.cpp:756)
==6025==    by 0x40CB18: Recognition::OutputImage::encode() (output_image.cpp:58)
==6025==    by 0x403AD4: main (testImgNorm.cpp:127)

因此，在查看mem_empty_output_buffer()调用后，我认为这个内存泄漏是由以下原因造成的：

1-libjpeg-8c写得很糟糕（它的函数和其调用者接口显然也不清楚），但考虑到这个库的广泛使用，我表示怀疑。

2-CompressRawToJpeg()应该在*j_compress_ptr中的某个malloc的缓冲区上调用free()。

3-这是libjpeg的真正错误，我应该使用其他库。

我希望有经历类似问题的人能够提供一种方法，让我的代码可以输出jpeg图像，而不会出现每个文件流失64K的内存块。

谢谢，Charles

- Charles Martin

---

也许可以通过这个答案解决？很难确定，因为您没有包含所有与jpeg相关的代码。 - ssbssa

Answer 1

问题很可能是jpeg_mem_dest()会分配自己的内存并忽略您提供的第二个参数：

uint8_t* output = NULL;
unsigned long outputSize = 0;
jpeg_mem_dest(&cInfo, &output , &outputSize);

当在编码过程结束时没有调用free()函数时，就会发生内存泄漏：

jpeg_finish_compress(&cinfo);
jpeg_destroy_compress(&cinfo);
free(output);

- karlphillip