1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

valgrind in jail

Discussion in 'Userland Programming and Scripting' started by Alt, Apr 28, 2012.

  1. Alt

    Alt New Member

    Messages:
    726
    Likes Received:
    0
    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.
     
  2. Zare

    Zare New Member

    Messages:
    386
    Likes Received:
    0
    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.
     
  3. matoatlantis

    matoatlantis Member

    Messages:
    532
    Likes Received:
    0
    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).
     
  4. Alt

    Alt New Member

    Messages:
    726
    Likes Received:
    0
    Your int* will be cut by the compiler cus because it is not used.
     
  5. matoatlantis

    matoatlantis Member

    Messages:
    532
    Likes Received:
    0
    I thought about that too. But I did do a dummy assignment using either memset or directly setting values - same results.