valgrind in jail

Alt · #1 April 28th, 2012, 08:39

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.

Zare · #2 April 28th, 2012, 10:41

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.

matoatlantis · #3 April 28th, 2012, 20:34

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 · #4 May 1st, 2012, 16:58

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

matoatlantis · #5 May 1st, 2012, 17:35

Quote:

Originally Posted by Alt

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.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
[Solved] Jail and NAT	SacamantecaS	Networking	2	September 20th, 2011 15:23
[Solved] Jail failed to telnet to other jail.	sixtydoses	Networking	4	April 19th, 2011 11:52
Jail can resolve, sometimes. Jail can connect, sometimes.	helplease	Firewalls	3	February 25th, 2011 00:41
[Solved] Error starting jail on 8.1# jail: execvp: /bin/sh: Exec format error	ghostcorps	General	5	September 13th, 2010 04:34
valgrind on FreeBSD	lyuts	Userland Programming & Scripting	3	December 16th, 2008 17:26