# valgrind in jail



## Alt (Apr 28, 2012)

Hello gentlemen, *I* have *an* issue with valgrind - seems it*'*s not working in *a* jail (on my VPS). Sample program: 
	
	



```
#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: 
	
	



```
==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: 
	
	



```
==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.


----------



## Zare (Apr 28, 2012)

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.


----------



## _martin (Apr 28, 2012)

I don't know how memory management is handled in *a* jail, but for me the following demo program leak.c: 
	
	



```
#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`

```
==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 (May 1, 2012)

Your int* will be cut by the compiler cus because it is not used.


----------



## _martin (May 1, 2012)

Alt said:
			
		

> Your int* will be cut by compiler because it is not used



I thought about that too. But I did do a dummy assignment using either memset or directly setting values - same results.


----------

