drmemory icon indicating copy to clipboard operation
drmemory copied to clipboard

Drfuzz unable to inject.

Open Pastoray opened this issue 6 months ago • 0 comments

Describe the bug Following the docs, i tried using Drfuzz to get a hang of how it works, however doesn't seem to work at all, even when there are leaks and other problems with the program, i also found this which i believe is another way to use drfuzz, i haven't experimented with it as much but it also is not working as expected but that might be a different issue.

To Reproduce

  1. Use the following Docker image to build drmemory and compile the program:
FROM ubuntu:16.04

ENV DEBIAN_FRONTEND=noninteractive

RUN apt-get update

RUN apt-get install -y --no-install-recommends \
    software-properties-common \
    ca-certificates \
    wget \
    git \
    make

RUN add-apt-repository ppa:ubuntu-toolchain-r/test -y

RUN wget -O - https://apt.kitware.com/keys/kitware-archive-latest.asc | apt-key add -
RUN echo "deb https://apt.kitware.com/ubuntu/ xenial main" > /etc/apt/sources.list.d/kitware.list

RUN apt-get update

RUN apt-get install -y --no-install-recommends \
    gcc-9 \
    g++-9 \
    g++-9-multilib \
    build-essential \
    cmake \
    doxygen \
    zlib1g-dev \
    libunwind-dev \
    libsnappy-dev

RUN mkdir -p /tmp/xxhash_build
WORKDIR /tmp/xxhash_build
RUN git clone https://github.com/Cyan4973/xxhash.git . && \
    make install PREFIX=/usr/local

WORKDIR / # Go back to root to remove the build directory
RUN rm -rf /tmp/xxhash_build

RUN mkdir -p /tmp/lz4_build
WORKDIR /tmp/lz4_build
RUN git clone https://github.com/lz4/lz4.git . && \
    git checkout v1.9.3 && \
    make && \
    make install PREFIX=/usr/local

WORKDIR / # Go back to root to remove the build directory
RUN rm -rf /tmp/lz4_build

RUN ldconfig

RUN update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-9 90 --slave /usr/bin/g++ g++ /usr/bin/g++-9 --slave /usr/bin/gcov gcov /usr/bin/gcov-9
RUN update-alternatives --install /usr/bin/cc cc /usr/bin/gcc 30
RUN update-alternatives --set cc /usr/bin/gcc

RUN rm -rf /var/lib/apt/lists/*

CMD ["bash"]
  1. Build drmemory with script:
#!/bin/bash

# This script is meant to be run *inside* the Docker container.
# It cleans the build directory, sets necessary environment variables,
# and runs cmake and make.

# Exit immediately if a command exits with a non-zero status.
set -e

# Define the build directory (relative to the script's location, which should be /code)
BUILD_DIR="build"

echo "--- Starting build process in Docker container ---"

# Create build directory if it doesn't exist
mkdir -p "$BUILD_DIR"
cd "$BUILD_DIR"

echo "--- Cleaning previous build files in $(pwd) ---"
rm -rf *

echo "--- Setting environment variables ---"
export CMAKE_PREFIX_PATH=/usr/local
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH

echo "--- Running cmake ---"
cmake .. \
  -DCMAKE_CXX_STANDARD=17 \
  -DCMAKE_BUILD_TYPE=Release \
  -DCMAKE_EXE_LINKER_FLAGS="-L/usr/local/lib -Wl,-rpath=/usr/local/lib" \
  -DCMAKE_SHARED_LINKER_FLAGS="-L/usr/local/lib -Wl,-rpath=/usr/local/lib" \
  -DCMAKE_EXPORT_COMPILE_COMMANDS=ON

echo "--- Running make ---"
make -j$(nproc) # Use all available CPU cores for faster compilation

echo "--- Build complete! ---"
  1. build test program with gcc -g -fno-inline -fno-omit-frame-pointer main.c -o main or gcc main.c -o main (neither work), the program:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int global_uninitialized_array[10];

void MyFuzzFunc(const char *buffer, size_t size) {
    printf("Fuzz iteration: size = %zu\n", size);

    void *leaked_mem = malloc(256);
    if (leaked_mem == NULL) {
        fprintf(stderr, "Memory allocation failed for leak test!\n");
        return;
    }
    memset(leaked_mem, 0xAA, 256); // Just to use it and prevent compiler optimization
    printf("Reading uninitialized global: %d\n", global_uninitialized_array[0]);
}

int main() {
    printf("My fuzz target application started.\n");
    return 0;
}
  1. Run : drmemory/build/bin64/drmemory -fuzz_target 'main!MyFuzzFunc|2|0|1|1' -- ./main or : drmemory/build/bin64/drmemory -fuzz_module main -fuzz_function MyFuzzFunc -fuzz_num_args 2 -fuzz_data_idx 0 -fuzz_size_idx 1 -fuzz_num_iters 10000 -- ./main

Please also answer these questions drawn from https://drmemory.org/page_help.html#sec_narrow :

  • Does the problem go away when running in light mode (pass -light to Dr. Memory)? No
  • Does the problem go away when running with the options -leaks_only -no_count_leaks -no_track_allocs? No
  • Does the problem go away when running under plain DynamoRIO? Do this by running dynamorio/bin32/drrun -- <application and args> or dynamorio/bin64/drrun -- <application and args> depending on the bitwidth of your applicaiton. (Ignore warnings about "incomplete installation".) No
  • What happens with the debug version of Dr. Memory and of its underlying engine DynamoRIO? Try this by passing -debug -dr_debug -pause_at_assert. Are any messages reported? "ERROR: unable to inject"

Expected behavior Drmemory reporting all the errors in one go correctly, that's what i expected according to 1797 i wanted to replicate it to get a better hang of Drfuzz.

Screenshots or Pasted Text

```
~~Dr.M~~ Dr. Memory version 2.6.20253
My fuzz target application started.
~~Dr.M~~ 
~~Dr.M~~ NO ERRORS FOUND:
~~Dr.M~~       0 unique,     0 total unaddressable access(es)
~~Dr.M~~       0 unique,     0 total uninitialized access(es)
~~Dr.M~~       0 unique,     0 total invalid heap argument(s)
~~Dr.M~~       0 unique,     0 total warning(s)
~~Dr.M~~       0 unique,     0 total,      0 byte(s) of leak(s)
~~Dr.M~~       0 unique,     0 total,      0 byte(s) of possible leak(s)
~~Dr.M~~ ERRORS IGNORED:
~~Dr.M~~       1 unique,     1 total,   1024 byte(s) of still-reachable allocation(s)
~~Dr.M~~          (re-run with "-show_reachable" for details)
~~Dr.M~~ Details: /tmp/Dr. Memory/DrMemory-main.17286.000/results.txt
```

Versions

  • What version of Dr. Memory are you using? 2.6.20253
  • Does the latest build from https://drmemory.org/page_download.html#sec_latest_build solve the problem? Nope
  • What operating system version are you running on? ("Windows 10" is not sufficient: give the release number.) Arch Linux 6.12.33-1-lts (But keep in mind everything is happening in the docker container so it's perhaps more appropriate to specify ubuntu:16.04)
  • Is your application 32-bit or 64-bit? 64-bit

Additional context I might be misusing this, am still not entirely sure.

Pastoray avatar Jun 19 '25 14:06 Pastoray