valgrind in jail

Alt

Alt

Hello gentlemen, I have an issue with valgrind - seems it's not working in a jail (on my VPS). Sample program:
Code: 
#include <iostream>                                                                                             
int main() {                                                                                                    
  int *a = new int(5);                                                                                        
  std::cout << *a << std::endl;                                                                               
  return 0;                                                                                                   
}

Compiling with g++ -g memleak.cpp; now runnig valgrind --leak-check=full ./a.out

This is output from my ubuntu @work:
Code: 
==4372== Memcheck, a memory error detector
==4372== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==4372== Using Valgrind-3.6.1-Debian and LibVEX; rerun with -h for copyright info
==4372== Command: ./a.out
==4372== 
5
==4372== 
==4372== HEAP SUMMARY:
==4372==     in use at exit: 4 bytes in 1 blocks
==4372==   total heap usage: 1 allocs, 0 frees, 4 bytes allocated
==4372== 
==4372== 4 bytes in 1 blocks are definitely lost in loss record 1 of 1
==4372==    at 0x402842F: operator new(unsigned int) (vg_replace_malloc.c:255)
==4372==    by 0x8048638: main (memleak.cpp:3)
==4372== 
==4372== LEAK SUMMARY:
==4372==    definitely lost: 4 bytes in 1 blocks
==4372==    indirectly lost: 0 bytes in 0 blocks
==4372==      possibly lost: 0 bytes in 0 blocks
==4372==    still reachable: 0 bytes in 0 blocks
==4372==         suppressed: 0 bytes in 0 blocks
==4372== 
==4372== For counts of detected and suppressed errors, rerun with: -v
==4372== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 17 from 6)

That's ok.

But on a VPS jail I got this:
Code: 
==24647== Memcheck, a memory error detector
==24647== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==24647== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==24647== Command: ./a.out
==24647== 
==24647== Conditional jump or move depends on uninitialised value(s)
==24647==    at 0x2C38C: ??? (in /vs/disk/MY_IP/libexec/ld-elf.so.1)
==24647==    by 0x2C02C: ??? (in /vs/disk/MY_IP/libexec/ld-elf.so.1)
==24647==    by 0x4A03F: ???
==24647==    by 0x4A00F: ???
==24647==    by 0x7FEFFF70F: ???
==24647==    by 0x1A868: ??? (in /vs/disk/MY_IP/libexec/ld-elf.so.1)
==24647==    by 0x7FEFFF71E: ???
==24647==    by 0x1AECE: ??? (in /vs/disk/MY_IP/libexec/ld-elf.so.1)
==24647== 
--24647-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x2a

valgrind: m_debuginfo/readdwarf.c:2338 (copy_convert_CfiExpr_tree): Assertion 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed.
==24647==    at 0x3802B517: ??? (in /usr/local/lib/valgrind/memcheck-amd64-freebsd)
==24647==    by 0x3802B74B: ??? (in /usr/local/lib/valgrind/memcheck-amd64-freebsd)
==24647==    by 0x38089DC1: ??? (in /usr/local/lib/valgrind/memcheck-amd64-freebsd)
==24647==    by 0x3808A237: ??? (in /usr/local/lib/valgrind/memcheck-amd64-freebsd)
==24647==    by 0x3808A7D3: ??? (in /usr/local/lib/valgrind/memcheck-amd64-freebsd)
==24647==    by 0x3808C290: ??? (in /usr/local/lib/valgrind/memcheck-amd64-freebsd)
==24647==    by 0x38056F06: ??? (in /usr/local/lib/valgrind/memcheck-amd64-freebsd)
==24647==    by 0x38053359: ??? (in /usr/local/lib/valgrind/memcheck-amd64-freebsd)
==24647==    by 0x380701D6: ??? (in /usr/local/lib/valgrind/memcheck-amd64-freebsd)
==24647==    by 0x38081A32: ??? (in /usr/local/lib/valgrind/memcheck-amd64-freebsd)
==24647==    by 0x38066E64: ??? (in /usr/local/lib/valgrind/memcheck-amd64-freebsd)
==24647==    by 0x380636BD: ??? (in /usr/local/lib/valgrind/memcheck-amd64-freebsd)
==24647==    by 0x38064727: ??? (in /usr/local/lib/valgrind/memcheck-amd64-freebsd)
==24647==    by 0x3807DD33: ??? (in /usr/local/lib/valgrind/memcheck-amd64-freebsd)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable
==24647==    at 0x1B94C: ??? (in /vs/disk/MY_IP/libexec/ld-elf.so.1)
==24647==    by 0x17899: ??? (in /vs/disk/MY_IP/libexec/ld-elf.so.1)
==24647==    by 0x120030517: ???
==24647==    by 0xFFF: ???
==24647==    by 0x7FF: ???
==24647==    by 0x3FFF: ???
==24647==    by 0x4E1FFF: ???
==24647==    by 0x10E574: ???
==24647==    by 0x10E574: ???
==24647==    by 0x270FFF: ???
==24647==    by 0x20DD77: ???

How can I fix this? Or maybe valgrind is not able to run in a jail?
Thanks for advance.
 
I don't know how memory management is handled in a jail, but for me the following demo program leak.c:
Code: 
#include <stdio.h>
#include <stdlib.h>

int main() {
        int* leak = (int*)malloc(sizeof(int)*3);

        return 1;
}

compiled with cc -g leak.c gives me the following output:

# valgrind --leak-check=full --show-reachable=yes ./a.out
Code: 
==61771== Memcheck, a memory error detector
==61771== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==61771== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==61771== Command: ./a.out
==61771==
==61771==
==61771== HEAP SUMMARY:
==61771==     in use at exit: 0 bytes in 0 blocks
==61771==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==61771==
==61771== All heap blocks were freed -- no leaks are possible
==61771==
==61771== For counts of detected and suppressed errors, rerun with: -v
==61771== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

While on the host I can clearly see the leak (FreeBSD 9.0).
 
Alt said:
Your int* will be cut by compiler because it is not used
Click to expand...

I thought about that too. But I did do a dummy assignment using either memset or directly setting values - same results.
 
Zare said:
Valgrind runs the target program inside a JIT virtual machine. It shouldn't be affected by jail limits.
Deinstall the 3.6.1 port, pull the 3.7.0 source from https://bitbucket.org/stass/valgrind-freebsd, build, install, test.
Click to expand...

Old thread, but I want to reply to the "It shouldn't be affected by jail limits".

That's definitely not true. I did look into using jails for testing the development of Valgrind itself. Whilst it will work, there are numerous restrictions. Some things won't work, some will work differently. Since jails are not up to that job I use VirtualBox. I have had some issues with Vbox not providing some opcodes that are available on the host but otherwise it's good enough.

Conclusion: you'll get the best results without any form of virtualization, and I only recommend that you use Valgrind in a jail if you have no other choice.
 
You must log in or register to reply here.
Back
Top