Valgrind를 공부(활용?)해봅니다.

A) To profile specific functions in an already running application using Valgrind, use the Callgrind tool with conditional instrumentation. Start with instrumentation off (--instr-atstart=no), then use callgrind_control to enable profiling only during the target function execution. Valgrind +2

To profile specific functions in a running application, use the Callgrind tool with conditional instrumentation. Start with instrumentation off (--instr-atstart=no). Use callgrind_control to enable profiling during target function execution. Valgrind

Steps to Trigger Profiling on a Running Application

1. Launch with Callgrind (Initially Disabled)
   Start the application with Callgrind. Instruct it not to start instrumentation immediately:bashvalgrind --tool=callgrind --instr-atstart=no ./your_app [args]
2. Locate Process ID (PID)
   Find the PID of the running Valgrind process. This is usually the first child process.
3. Trigger Profiling via Control Command
   When the application reaches the desired point, run this in another terminal:bashcallgrind_control -i on -p <PID>
4. Stop Profiling
   Once the target function finishes, turn off instrumentation to minimize overhead:bashcallgrind_control -i off -p <PID>
5. Dump Results
   Force a dump of the profile data:bashcallgrind_control -d -p <PID>  

Alternative: Programmatic Instrumentation (Recommended for accuracy)

Insert code directly into the application to control Valgrind: Valgrind

c

#include <valgrind/callgrind.h>

// Inside your code
CALLGRIND_START_INSTRUMENTATION;
// ... call the function you want to profile ...
target_function();
CALLGRIND_STOP_INSTRUMENTATION;

Compile with -I /path/to/valgrind/include and run without --instr-atstart=no. 

Useful Options

• --dump-instr=yes: Provides assembly-level, instruction-by-instruction profiling (viewable in KCachegrind).
• --collect-jumps=yes: Captures jump information for better performance analysis.
• --fn-skip=funcprefix: Ignores irrelevant functions to reduce noise. Valgrind +1

The results can be analyzed using {Link: KCachegrind https://kcachegrind.sourceforge.net/}. 

A) To trigger Valgrind Memcheck (leak check) or Callgrind (profiling) only during a specific function, use the Valgrind client request mechanism (VALGRIND_TOGGLE_CHECKING) in your C/C++ code. This allows enabling/disabling instrumentation dynamically, reducing performance overhead and focusing output. 

Steps to Implement Targeted Monitoring

1. Include the Valgrind Header:
   Include <valgrind/valgrind.h> in your source file.
2. Toggle Instrumentation in Code:
   Wrap the specific function call with toggling commands.c#include <valgrind/valgrind.h> void target_function() { // TURN ON VALGRIND VALGRIND_TOGGLE_CHECKING; // --- Code to profile/check for leaks --- do_work(); // TURN OFF VALGRIND VALGRIND_TOGGLE_CHECKING; }
3. Compile and Run:
   • Compile with debugging symbols (-g).
   • Run with valgrind --tool=memcheck --log-file=valgrind.log ./your_program. YouTube +4

Alternative Method: Using GDB and vgdb 

If you cannot modify the source code, you can use vgdb to toggle instrumentation remotely.

1. Run valgrind with: valgrind --vgdb-error=0 ./your_program.
2. In another terminal, use vgdb to toggle:bashvgdb monitor toggle_checking # Run your specific function here vgdb monitor toggle_checking  Valgrind +2

Key Considerations

Callgrind: For profiling, use CALLGRIND_TOGGLE_COLLECT from <valgrind/callgrind.h> to start/stop collection. Mantid Project +1

Performance: While disabled, code runs much faster than fully instrumented, but still slower than natively.

Leaks: For memory leaks, note that memory allocated while monitoring is OFF but freed while ON may cause confusing reports.

To trigger Valgrind profiling or memory leak checks in a target application only during a specific function’s execution without modifying the source, use valgrind --vgdb-error=0 to attach GDB, set a breakpoint at the target function, and issue manual leak checks (monitor leak_search) or start profiling when the breakpoint hits. This technique works by leveraging Valgrind’s GDB server. Valgrind +2

Steps to Trigger Profiling/Leakage Check on Demand

1. Run with Valgrind and GDB server:
   Start the target application under Valgrind, enabling the GDB server:bashvalgrind --vgdb=yes --vgdb-error=0 --leak-check=full ./your_app --vgdb-error=0 makes Valgrind wait for a GDB client before executing the first instruction.
2. Attach GDB in a new terminal:
   Find the PID of the process (Valgrind will display it) and attach GDB:bashgdb ./your_app (gdb) target remote | vgdb
3. Set Breakpoint on Specific Function:
   Set a breakpoint on the target function where profiling or checking for leaks should start:bash(gdb) break your_function_name (gdb) continue
4. Trigger Specific Actions via GDB (No Code Change):
   When the program hits your_function_name, GDB will stop. Then, instruct Valgrind:
   • To check for memory leaks at this point:bash(gdb) monitor leak_search
   • To start profiling (if using Callgrind):bash(gdb) monitor callgrind_control -i on
5. Stop/Resume:
   Continue execution and trigger monitor leak_search again later. Valgrind +4

Alternative: Using valgrind/valgrind.h (Minimal Modification) 

If allowed to add one line to the code (#include <valgrind/valgrind.h>), insert VALGRIND_DO_LEAK_CHECK; directly inside the specific function. However, this requires recompilation. The GDB method requires no code modifications

You can achieve selective profiling or leakage checks in Valgrind without modifying the target application’s source code or using GDB by leveraging the callgrind_control utility or the vgdb command-line utility with monitor commands. Stack Overflow +1

For Profiling (Callgrind)

The callgrind_control utility is designed specifically for toggling instrumentation and collection during a program’s execution. Stack Overflow +2

1. Launch your application under Valgrind’s Callgrind tool, but with instrumentation and collection turned off at the start:bashvalgrind --tool=callgrind --instr-atstart=no --collect-atstart=no ./your_executable [args...]
2. Identify the application’s PID. Valgrind will print the PID when it starts.
3. Trigger profiling start just before the function you are interested in is executed. You will need to switch to another terminal and run the callgrind_control command with the application’s PID:bashcallgrind_control -i on --pid=<PID>
4. Trigger profiling stop after the function has completed its execution:bashcallgrind_control -i off --pid=<PID>  

This approach allows you to profile only the desired section of code, minimizing the overhead for uninteresting parts. Stack Overflow

For Leakage Checks (Memcheck)

For memory error and leak detection using the default Memcheck tool, there is no direct command-line option like callgrind_control to selectively start/stop checks without recompiling with client request macros. Stack Overflow

However, you can use the vgdb command-line utility to send “monitor commands” to the Valgrind gdbserver, although this is more complex and typically used in conjunction with GDB. The user can achieve some level of control this way, but it is not as straightforward as the callgrind_control method. Stack Overflow +2

A common approach for Memcheck is to use suppressions files to ignore errors in known library functions or parts of the code you do not control. This does not trigger the check only for a specific function but helps in filtering out irrelevant results. Sourceware

For precise control over Memcheck without source code modification, the use of GDB to set breakpoints and issue monitor commands for starting/stopping error detection remains the most reliable method. Stack Overflow +3

You can control Valgrind’s memory checking for specific functions using the Valgrind client requests VALGRIND_START_MEMCHECK and VALGRIND_STOP_MEMCHECK macros within your code. This requires including the valgrind/valgrind.h header and linking against the Valgrind client library. 

Below is an exact C source code example that demonstrates this approach in a daemon-style program (using a simple infinite loop) with one function that leaks memory and another that does not. 

Source Code Example (daemon_leak_example.c) 

c

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h> // For sleep function
#include <valgrind/valgrind.h> // Required for Valgrind client requests

// Function with a definite memory leak
void function_with_leak(void) {
    char *ptr;
    // Start Valgrind memory checking specifically for this function
    VALGRIND_START_MEMCHECK;

    ptr = malloc(1024); // Allocate memory
    if (ptr == NULL) {
        perror("malloc failed");
        return;
    }
    // No free call, so this is a leak

    printf("Leak function ran, allocated 1024 bytes (will be reported by Valgrind).\n");

    // Stop Valgrind memory checking
    VALGRIND_STOP_MEMCHECK;
}

// Function with no memory leak
void function_without_leak(void) {
    char *ptr;
    // Start Valgrind memory checking
    VALGRIND_START_MEMCHECK;

    ptr = malloc(1024); // Allocate memory
    if (ptr == NULL) {
        perror("malloc failed");
        return;
    }
    free(ptr); // Free the allocated memory

    printf("No leak function ran, allocated and freed 1024 bytes (will not be reported).\n");

    // Stop Valgrind memory checking
    VALGRIND_STOP_MEMCHECK;
}

int main(void) {
    printf("Daemon-style application starting...\n");
    printf("Valgrind should only monitor inside the instrumented functions.\n");

    while (1) { // Simulate a daemon's infinite loop
        function_without_leak();
        sleep(2); // Wait a bit
        function_with_leak();
        sleep(2); // Wait a bit
    }

    // This part is unreachable in a true infinite loop, but a real daemon
    // would handle termination signals and clean up here. Valgrind reports
    // leaks at exit, so the process must eventually terminate for a final summary.
    return 0;
}

How to Compile and Run

1. Install Valgrind Development Headers: Make sure you have the necessary headers installed (e.g., valgrind-devel or valgrind-dbg package in most Linux distributions).
2. Compile: Compile your code with the -g flag for line numbers and link the Valgrind client requests library using the -lvalgrind flag.bashgcc -g daemon_leak_example.c -o daemon_leak_example -lvalgrind
3. Run with Valgrind: Run the executable with Valgrind’s memcheck tool. To only track memory within the instrumented sections and see a final leak summary at exit, use --leak-check=full and potentially suppress initial errors with --instr-atstart=no (though the client requests handle the start/stop manually).Important: Valgrind’s final leak summary is reported when the program terminates. For a daemon, you would typically send a termination signal (SIGINT or SIGTERM) to allow a graceful shutdown and leak report. In this example, the infinite loop is a simplification.To observe the effects, you can interrupt the running program after a few iterations (using Ctrl+C or kill) to see the current memory state, but the most comprehensive leak report happens at the program’s normal exit.bashvalgrind --leak-check=full --show-leak-kinds=definite ./daemon_leak_example  University of Wisconsin–Madison +4

Expected Output

When you run the program and eventually terminate it, Valgrind’s output will focus on the leaks that occurred within the VALGRIND_START_MEMCHECK/VALGRIND_STOP_MEMCHECK blocks that were not freed, specifically from function_with_leak. The memory allocated and freed in function_without_leak will not show up as a leak in the final report. 

The output will include a summary similar to:

==...== definite lost: 1,024 bytes in 1 blocks from function_with_leak ...

This confirms Valgrind only checked the specific code sections you marked. 

To control Valgrind’s Memcheck from a C/C++ application without using the unsupported VALGRIND_START_MEMCHECK macro, use VALGRIND_DISABLE_ERROR_REPORTING and VALGRIND_ENABLE_ERROR_REPORTING macros from <valgrind/memcheck.h>. These stop reporting errors, though they do not pause instrumentation overhead. Valgrind +2

Proper Control Method

To analyze a specific function, wrap the code with these macros to silence Valgrind during unnecessary sections.

c

#include <valgrind/memcheck.h>
#include <stdlib.h>

void function_to_test() {
    // START CHECKING
    VALGRIND_ENABLE_ERROR_REPORTING;
    
    int *x = malloc(10 * sizeof(int));
    // Memory leak: x is not freed
    
    // STOP CHECKING
    VALGRIND_DISABLE_ERROR_REPORTING;
}

int main() {
    // Initial, unmonitored work
    function_to_test();
    return 0;
}

Key Considerations

Note: These macros still incur the performance cost of running under Valgrind, they simply tell the tool to stop reporting the errors. Valgrind +4

Compilation: Compile with -g for debug symbols and include valgrind.h and memcheck.h.

Alternative for Specific Leaks: Use VALGRIND_DO_LEAK_CHECK to force a leak report at a specific, targeted point in the code, rather than waiting for program termination.

Run Command: valgrind --tool=memcheck --leak-check=full ./your_program.