Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
A real-time memory trace visualizer using valgrind
C C++ GLSL Makefile QMake
Branch: master

Use a separate QLabel for zoom status.

Trying to create a single string containing a left-justified status message as well as a right-justified zoom was problematic, since the Monospace font no longer seems to have a constant ' ' width. Instead, split it into 2 widgets - one to show the message (left) and another the zoom (right).
latest commit fb711fb8fe
@ajclinto authored
Failed to load latest commit information.
debian Correct shader program references.
pin Change tabs to 8 spaces
screenshots Add some screenshots.
test Change tabs to 8 spaces
valgrind Change tabs to 8 spaces
.gitignore Add automated debian package builder.
COPYING Add a copyright and license (GNU GPL v2 to match the valgrind license).
Color.h Change tabs to 8 spaces
DisplayLayout.C Change tabs to 8 spaces
DisplayLayout.h Change tabs to 8 spaces
GLImage.h Change tabs to 8 spaces
IntervalMap.C Rename SparseMap to IntervalMap and add a unit test for this class.
IntervalMap.h Change tabs to 8 spaces
Loader.C Change tabs to 8 spaces
Loader.h Change tabs to 8 spaces
Math.h Change tabs to 8 spaces
MemoryState.C Use a separate QLabel for zoom status.
MemoryState.h Change tabs to 8 spaces
README.md Automate the tool build process.
SparseArray.h Change tabs to 8 spaces
StopWatch.h Change tabs to 8 spaces
Window.C Use a separate QLabel for zoom status.
Window.h Use a separate QLabel for zoom status.
main.C Change tabs to 8 spaces
memview.frag Change tabs to 8 spaces
memview.pro Rename SparseMap to IntervalMap and add a unit test for this class.
memview.vert Upgrade patches to valgrind 3.10.
mv_ipc.h Change tabs to 8 spaces

README.md

Summary

Memview is a real-time visualization program that will show the memory state of another running program as a graphical image. Memory addresses correspond to pixels in the image, and as memory is accessed the display will animate to show what parts of the address space are currently being referenced by the program.

It was written primarily to satisfy my curiosity about how different programs use their address space, and to serve as a visual debugger to help find memory performance problems relating to locality. It can also be plain fun to watch the memory of a complex algorithm!

Building

Before you start, you'll need:

  • Qt4: libqt4-dev libqt4-opengl-dev
  • A GPU with OpenGL 3.0 support
  • Tested compilers are gcc 4.4 and 4.7

Build the visualizer front end:

qmake
make -j<nprocs>

Build the valgrind tool. This will automatically download the valgrind source code prior to patching and building it:

cd valgrind
make -j<nprocs>

Execution

If you built the front and tool successfully, the following command should work:

./memview ls

If you were unable to build the valgrind tool but you have a valgrind binary installed, you can try the front end (without the tool) using:

./memview --tool=lackey ls

Lackey is orders of magnitude slower than the memview tool, and doesn't support stack traces and allocation tracking - but you can get an idea of how the memory trace visualization works.

Documentation

Memview UI

Layout

Memview maps the program address space to pixels in the image. At the initial zoom level of 1, each pixel in the image corresponds to 4 bytes of memory.

By default, the 1D address space is converted to a 2D image using a hilbert curve. This kind of mapping tends to map nearby memory addresses to nearby pixels - so that locality of reference is immediately apparent. It's possible to layout the memory in other ways using the options in the 'Layout' menu.

To navigate the address space, use controls similar to Google maps:

  • Left click/drag to pan
  • Mouse wheel to zoom (each step is a factor of 2)
  • Scroll bars to scroll

Often there are large holes in the address space (for example, between the heap and the stack) - these are automatically collapsed to eliminate empty space in the image. This means that if the program eventually makes use of memory in one of these holes, the display will shift the existing data to accomodate the newly visible addresses. If you want to see the entire address space without any collapsing, change the layout from 'Compact' to 'Full Size' in the 'Layout' menu.

Display

In the default 'Read/Write' display mode, different colors indicate different types of memory accesses:

  • Bright green : Recently read
  • Dark blue : Previously read
  • Bright yellow : Recently written
  • Dark red : Previously written
  • Bright pink : Recent instruction read
  • Dark purple : Previous instruction read
  • Gray : Allocated, unreferenced memory
  • Dimmed : Freed memory

Brighter colors indicate more recent references. You can point at a pixel and look at the status bar to see the address and mapping information corresponding to that pixel, as well as the type for the most recent memory operation at that address.

The 'Thread Ids' display mode will color the memory based on the thread that most recently touched that memory.

The 'Data Type' display mode will color the memory based on the data type that valgrind reported. Be aware that the data type may not be accurate, since machine instructions that access memory do not always specify the data type.

The 'Mapped Regions' display mode will show the intervals in memory that correspond to the different memory mappings in the program. Each different mapped region will display using a different color. If you want to see the full extent of the mapped regions, change the layout to 'Full Size' - otherwise the mapped regions will only appear where memory has been referenced.

During execution, stack traces are periodically sampled and sent to the visualizer. These can be inspected by hovering the cursor over the image - the closest stack trace will be displayed as a tooltip. To view the location of the stacks that have been recorded, use the 'Stack Traces' display mode.

Data Type

Data display

If you zoom in far enough, memview will populate the zoomed in pixels with the actual data that is present in those memory locations. By default it will display the values based on the type reported by valgrind, but you can override the data display type using the settings in the 'Data Type' menu.

Something went wrong with that request. Please try again.