使用 vfwprintf 时，Valgrind 报告“仍然可以访问”字节

Question

I am writing two functions as handy shortcuts for printing to stderr : one I am calling eprintf for printing regular strings; and ewprintf for printing wide-character strings. I have written eprintf as follows:

int eprintf(const char* fmt, ...) {
    va_list args;
    va_start(args, fmt);
    int written = vfprintf(stderr, fmt, args);
    va_end(args);
    return written;
}

ewprintf is the same except that its fmt parameter is of type const wchar_t* and I use vfwprintf to write to stderr .

I have these two functions declared in a header file called eprintf.h and then defined in eprintf.c . My main function is simply designed to test these:

#include <stdio.h>
#include <stdlib.h>
#include <locale.h>
#include "eprintf.h"

int main(int argc, char** argv) {
    setlocale(LC_ALL, "");
    ewprintf(L"This is a test.\n");
    return 0;
}

I replaced ewprintf with eprintf and then tested the program with valgrind and had no issues--there were an equal number of allocs to frees, with no bytes labeled as "still reachable"; however, when using ewprintf --which calls vfwprintf --valgrind reports that 5120 bytes in two blocks are "still reachable," with 33 allocs but only 31 frees. Running a more detailed leak check to find the cause of the "still reachable" memory, valgrind provides a trace that includes vfwprintf .

I have also tried defining eprintf and ewprintf as variadic macros just like those seen here . But, I ran into the same issue with ewprintf written as a macro.

So, my first question: in this case, is this "still reachable" issue actually something to be concerned with? Note that valgrind does not report any bytes as "definitely lost," "indirectly lost," or "possibly lost." Second, even if this is not actually a problem per se, is there anything I can do to fix it?

Update: here is my implementation for ewprintf for further clarification:

// Notice that its parameter is a wide-character string, and it calls `vfwprintf`.
int ewprintf(const wchar_t* fmt, ...) {
    va_list args;
    va_start(args, fmt);
    int written = vfwprintf(stderr, fmt, args);
    va_end(args);
    return written;
}

Answer 1

Short Answer:

Buffers are associated with stderr . Possible to get rid of the message by explicit closing(stderr) before exit, but see note below.

Long Answer:

According to valgrind, the 'still reachable' memory was allocated from buffered writes for vfwprintf. Those are buffered that are associated with stderr, and are allocated on the first call.

The buffers are automatically closed when stderr is closed. Usually, this is done just before the program exit. Looks like valgrind reporting hooks are executed before the final exit. Possible to get rid of this message by explicitly closing stderr in main . See below.

While possible to use this option, I think that it's better to leave stderr open, just in case something will need to be shown during program exit (eg, atexit , or other cleanup functions). Code that will attempt to access stderr, will crash the program without any useful message to help debug.

Edit 1:

According to valgrind documentation ( http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.clientreq ) possible to use the macro RUNNING_ON_VALGRIND to detect if running under valgrind, potentially closing stderr only on this condition. disclaimer: I do not have any actual experience using this macro, use with care.

int main(int argc, char** argv) {
    setlocale(LC_ALL, "");
    ewprintf(L"This is a test.\n");
    fclose(stderr) ;
    return 0;
}

valgrind --leak-check=full --show-leak-kinds=all ./a.out

==38349== Memcheck, a memory error detector
==38349== Command: ./a.out
==38349== 
This is a test.
==38349== 
==38349== HEAP SUMMARY:
==38349==     in use at exit: 5,120 bytes in 2 blocks
==38349==   total heap usage: 32 allocs, 30 frees, 9,500 bytes allocated
==38349== 
==38349== 1,024 bytes in 1 blocks are still reachable in loss record 1 of 2
==38349==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==38349==    by 0x4EBA18B: _IO_file_doallocate (filedoalloc.c:101)
==38349==    by 0x4EBB88C: _IO_wfile_doallocate (wfiledoalloc.c:70)
==38349==    by 0x4ECA378: _IO_doallocbuf (genops.c:365)
...
==38349==    by 0x4EA7089: buffered_vfprintf (vfprintf.c:2343)
==38349==    by 0x4EA40FD: vfwprintf (vfprintf.c:1301)
==38349==    by 0x1087F1: ewprintf (in /home/owner/Projects/SO/58904606/a.out)
==38349==    by 0x108847: main (in /home/owner/Projects/SO/58904606/a.out)
==38349== 
==38349== 4,096 bytes in 1 blocks are still reachable in loss record 2 of 2
==38349==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==38349==    by 0x4EBB858: _IO_wfile_doallocate (wfiledoalloc.c:79)
==38349==    by 0x4ECA378: _IO_doallocbuf (genops.c:365)
...
==38349==    by 0x4EA7089: buffered_vfprintf (vfprintf.c:2343)
==38349==    by 0x4EA40FD: vfwprintf (vfprintf.c:1301)
==38349==    by 0x1087F1: ewprintf (in /home/owner/Projects/SO/58904606/a.out)
==38349==    by 0x108847: main (in /home/owner/Projects/SO/58904606/a.out)
==38349== 
==38349== LEAK SUMMARY:
==38349==    definitely lost: 0 bytes in 0 blocks
==38349==    indirectly lost: 0 bytes in 0 blocks
==38349==      possibly lost: 0 bytes in 0 blocks
==38349==    still reachable: 5,120 bytes in 2 blocks
==38349==         suppressed: 0 bytes in 0 blocks
==38349== 
==38349== For counts of detected and suppressed errors, rerun with: -v
==38349== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)