I have been trying to fix this issue for a while and I am out of ideas.
I would like to use libpropcs-dev api to access the /proc directory in Linux.
I have this peice of code so far:
#include <stdio.h>
#include <stdlib.h>
#include <proc/readproc.h>
#include <string.h>
#include <iostream>
using namespace std;
int main (){
PROCTAB* proc = openproc(PROC_FILLMEM | PROC_FILLSTAT | PROC_FILLSTATUS);
proc_t proc_info;
memset(&proc_info, 0, sizeof(proc_info));
while (readproc(proc, &proc_info) != NULL) {
fprintf(stdout, "%20s: \t%5d\t%5ld\n",
proc_info.cmd, proc_info.ppid,
proc_info.rss);
}
cout << "size of proc " << sizeof(proc) << "\n";
cout << "size of proc_info " << sizeof(proc_info) << "\n";
closeproc(proc);
return 1;
}
However, if I run it I get segfault. This is the output of valgrind:
==6492== Memcheck, a memory error detector
==6492== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==6492== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==6492== Command: ./a.out
==6492==
==6492== Invalid free() / delete / delete[] / realloc()
==6492== at 0x4C2EDEB: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6492== by 0x4E43846: readproc (in /lib/x86_64-linux-gnu/libprocps.so.4.0.0)
==6492== by 0x400B37: main (in /home/mohamad/Work/3000-myrepo/a.out)
==6492== Address 0x9ad2de89d83bae00 is not stack'd, malloc'd or (recently) free'd
==6492==
==6492== Invalid free() / delete / delete[] / realloc()
==6492== at 0x4C2EDEB: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6492== by 0x4E43857: readproc (in /lib/x86_64-linux-gnu/libprocps.so.4.0.0)
==6492== by 0x400B37: main (in /home/mohamad/Work/3000-myrepo/a.out)
==6492== Address 0x400c50 is in the Text segment of /home/mohamad/Work/3000-myrepo/a.out
==6492== at 0x400C50: __libc_csu_init (in /home/mohamad/Work/3000-myrepo/a.out)
==6492==
==6492== Invalid free() / delete / delete[] / realloc()
==6492== at 0x4C2EDEB: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6492== by 0x4E43868: readproc (in /lib/x86_64-linux-gnu/libprocps.so.4.0.0)
==6492== by 0x400B37: main (in /home/mohamad/Work/3000-myrepo/a.out)
==6492== Address 0x5409830 is in the Text segment of /lib/x86_64-linux-gnu/libc-2.23.so
==6492== at 0x5409830: (below main) (libc-start.c:325)
==6492==
==6492== Conditional jump or move depends on uninitialised value(s)
==6492== at 0x4E43873: readproc (in /lib/x86_64-linux-gnu/libprocps.so.4.0.0)
==6492== by 0x400B37: main (in /home/mohamad/Work/3000-myrepo/a.out)
==6492==
==6492== Invalid free() / delete / delete[] / realloc()
==6492== at 0x4C2EDEB: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6492== by 0x4E4388A: readproc (in /lib/x86_64-linux-gnu/libprocps.so.4.0.0)
==6492== by 0x400B37: main (in /home/mohamad/Work/3000-myrepo/a.out)
==6492== Address 0xffefffc38 is on thread 1's stack
==6492==
==6492== Conditional jump or move depends on uninitialised value(s)
==6492== at 0x4E43895: readproc (in /lib/x86_64-linux-gnu/libprocps.so.4.0.0)
==6492== by 0x400B37: main (in /home/mohamad/Work/3000-myrepo/a.out)
==6492==
==6492== Conditional jump or move depends on uninitialised value(s)
==6492== at 0x4C2EDA1: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6492== by 0x4E4389B: readproc (in /lib/x86_64-linux-gnu/libprocps.so.4.0.0)
==6492== by 0x400B37: main (in /home/mohamad/Work/3000-myrepo/a.out)
==6492==
==6492== Invalid free() / delete / delete[] / realloc()
==6492== at 0x4C2EDEB: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6492== by 0x4E4389B: readproc (in /lib/x86_64-linux-gnu/libprocps.so.4.0.0)
==6492== by 0x400B37: main (in /home/mohamad/Work/3000-myrepo/a.out)
==6492== Address 0x100000000 is not stack'd, malloc'd or (recently) free'd
==6492==
==6492== Invalid free() / delete / delete[] / realloc()
==6492== at 0x4C2EDEB: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6492== by 0x4E438AC: readproc (in /lib/x86_64-linux-gnu/libprocps.so.4.0.0)
==6492== by 0x400B37: main (in /home/mohamad/Work/3000-myrepo/a.out)
==6492== Address 0x400ad6 is in the Text segment of /home/mohamad/Work/3000-myrepo/a.out
==6492== at 0x400AD6: main (in /home/mohamad/Work/3000-myrepo/a.out)
==6492==
systemd: 0 1476
kthreadd: 0 0
kworker/0:0H: 2 0
mm_percpu_wq: 2 0
ksoftirqd/0: 2 0
rcu_sched: 2 0
rcu_bh: 2 0
migration/0: 2 0
watchdog/0: 2 0
cpuhp/0: 2 0
cpuhp/1: 2 0
watchdog/1: 2 0
migration/1: 2 0
ksoftirqd/1: 2 0
kworker/1:0H: 2 0
cpuhp/2: 2 0
watchdog/2: 2 0
migration/2: 2 0
ksoftirqd/2: 2 0
kworker/2:0H: 2 0
cpuhp/3: 2 0
watchdog/3: 2 0
migration/3: 2 0
ksoftirqd/3: 2 0
kworker/3:0H: 2 0
kdevtmpfs: 2 0
**continues to print all the processess running ...**
size of proc 8
size of proc_info 888
*** stack smashing detected ***: ./a.out terminated
==6492==
==6492== Process terminating with default action of signal 6 (SIGABRT)
==6492== at 0x541E428: raise (raise.c:54)
==6492== by 0x5420029: abort (abort.c:89)
==6492== by 0x54607E9: __libc_message (libc_fatal.c:175)
==6492== by 0x550215B: __fortify_fail (fortify_fail.c:37)
==6492== by 0x55020FF: __stack_chk_fail (stack_chk_fail.c:28)
==6492== by 0x400BF9: main (in /home/mohamad/Work/3000-myrepo/a.out)
==6492==
==6492== HEAP SUMMARY:
==6492== in use at exit: 336,896 bytes in 4 blocks
==6492== total heap usage: 235 allocs, 237 frees, 376,803 bytes allocated
==6492==
==6492== LEAK SUMMARY:
==6492== definitely lost: 0 bytes in 0 blocks
==6492== indirectly lost: 0 bytes in 0 blocks
==6492== possibly lost: 0 bytes in 0 blocks
==6492== still reachable: 336,896 bytes in 4 blocks
==6492== suppressed: 0 bytes in 0 blocks
==6492== Rerun with --leak-check=full to see details of leaked memory
==6492==
==6492== For counts of detected and suppressed errors, rerun with: -v
==6492== Use --track-origins=yes to see where uninitialised values come from
==6492== ERROR SUMMARY: 9 errors from 9 contexts (suppressed: 0 from 0)
Aborted (core dumped)
Once I run it under gdb I get the following:
Program received signal SIGSEGV, Segmentation fault.
__GI___libc_free (mem=0x57a7587f19463b00) at malloc.c:2951
2951 malloc.c: No such file or directory.
Help or pointers regarding my issue would be awesome. Thanks!
Related
#include <iostream>
#include <random>
int main()
{
int a;
int *arr;
a = 3;
arr = new int[a];
#pragma omp parallel for
for (int i = 0; i < a; i++)
arr[i] = i;
delete[] arr;
return 0;
}
When I test this simple code with valgrind, it saids:
==2606== HEAP SUMMARY:
==2606== in use at exit: 3,360 bytes in 7 blocks
==2606== total heap usage: 10 allocs, 3 frees, 108,892 bytes allocated
==2606==
==2606== LEAK SUMMARY:
==2606== definitely lost: 0 bytes in 0 blocks
==2606== indirectly lost: 0 bytes in 0 blocks
==2606== possibly lost: 912 bytes in 3 blocks
==2606== still reachable: 2,448 bytes in 4 blocks
==2606== suppressed: 0 bytes in 0 blocks
Am I misunderstanding openmp or memory allocation usage?
Without "#pragma omp parallel for", it doesn't make any issues.
UPDATE
==2682== 912 bytes in 3 blocks are possibly lost in loss record 4 of 5
==2682== at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2682== by 0x40149DA: allocate_dtv (dl-tls.c:286)
==2682== by 0x40149DA: _dl_allocate_tls (dl-tls.c:532)
==2682== by 0x4DE4322: allocate_stack (allocatestack.c:622)
==2682== by 0x4DE4322: pthread_create##GLIBC_2.2.5 (pthread_create.c:660)
==2682== by 0x4A4FDEA: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==2682== by 0x4A478E0: GOMP_parallel (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==2682== by 0x109184: main (main.cpp:10)
This is what --leak-check-full says.
This issue appears only on g++4.9.3. Consider the minimal code:
#include <iostream>
#include <Eigen/dense>
int main()
{
Eigen::MatrixXcd mat = Eigen::MatrixXcd::Identity(2,2);
std::cout << mat << std::endl;
}
I compiled it with -Og and -D_GLIBCXX_DEBUG (I needed both of these flag to trigger the error):
g++ -Og -D_GLIBCXX_DEBUG -I./eigen minimal.cpp
Running the program results in:
a.out(42247,0x7fff7cf9e300) malloc: * error for object 0x10c6ca3d0:
pointer being freed was not allocated
* set a breakpoint in malloc_error_break to debug Abort trap: 6
Valgrind spits out something along the lines:
==42296== Invalid free() / delete / delete[] / realloc()
==42296== at 0x10000B957: free (vg_replace_malloc.c:480)
==42296== by 0x100038594: std::basic_stringbuf<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::pbackfail(int) (in /opt/local/lib/libgcc/libstdc++.6.dylib)
==42296== by 0x1048056C7: ???
==42296== by 0x27: ???
==42296== by 0x1048053E7: ???
==42296== by 0x100038CA1: std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::overflow(int) (in /opt/local/lib/libgcc/libstdc++.6.dylib)
==42296== by 0x672A2E24: ???
==42296== by 0x1000033E7: ??? (in ./a.out)
==42296== Address 0x1000033d0 is in the Data segment of ./a.out
==42296==
(1,0) (0,0)
(0,0) (1,0)
==42296==
==42296== HEAP SUMMARY:
==42296== in use at exit: 111,830 bytes in 436 blocks
==42296== total heap usage: 523 allocs, 91 frees, 124,150 bytes allocated
==42296==
==42296== LEAK SUMMARY:
==42296== definitely lost: 0 bytes in 0 blocks
==42296== indirectly lost: 0 bytes in 0 blocks
==42296== possibly lost: 0 bytes in 0 blocks
==42296== still reachable: 76,948 bytes in 5 blocks
==42296== suppressed: 34,882 bytes in 431 blocks
I am not sure what's happening. Does anyone know if this is a g++ related issue or an Eigen issue? I am using the latest Eigen 3.2.5 and g++4.9.3 from MacPorts on OS X Yosemite.
PS: The error does not appear if I compile with clang or with g++5.
I'm trying out boost threads and I noticed from valgrind that it is leaking 320 bytes just from looping through an empty block of code. I found some posts on google from 2010 that suggests that they are likely a false positive from threads not closing before valgind runs through, but this is slightly different. In those examples you had a few blocks that were still reachable (therefor, freeable if threads were still running) where my run shows 8 as still reachable and 20 blocks as definitely lost. Is this something I should worry about, or am I somehow missing something? Thanks
The code
#include <boost/thread.hpp>
#include <iostream>
#define THREADS 20
void threadfunc(int workerid) {}
int main(int argc, char **argv){
boost::thread *threads[THREADS];
int i;
for (i = 0; i < THREADS; i++) {
threads[i] = new boost::thread(threadfunc, i);
}
for (i = 0; i < THREADS; i++) {
threads[i]->join();
}
}
Compile command
c++ -o example example.cpp -I /usr/include/boost -lboost_system -lboost_thread
Valgind command
G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --leak-check=full --show-reachable=yes --num-callers=40 --log-file=valgrind.log ./example
Valgine results
==31674== HEAP SUMMARY:
==31674== in use at exit: 328 bytes in 21 blocks
==31674== total heap usage: 103 allocs, 82 frees, 14,968 bytes allocated
==31674==
==31674== Searching for pointers to 21 not-freed blocks
==31674== Checked 215,920 bytes
==31674==
==31674== 8 bytes in 1 blocks are still reachable in loss record 1 of 2
==31674== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31674== by 0x4E454A9: boost::detail::get_once_per_thread_epoch() (in /usr/lib/libboost_thread.so.1.46.1)
==31674== by 0x4E3E4FF: ??? (in /usr/lib/libboost_thread.so.1.46.1)
==31674== by 0x4E3E7C8: boost::detail::get_current_thread_data() (in /usr/lib/libboost_thread.so.1.46.1)
==31674== by 0x4E3FF3A: boost::thread::join() (in /usr/lib/libboost_thread.so.1.46.1)
==31674== by 0x402C79: main (in /home/Jason/php/base/example)
==31674==
==31674== 320 bytes in 20 blocks are definitely lost in loss record 2 of 2
==31674== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31674== by 0x402C2A: main (in /home/Jason/php/base/example)
==31674==
==31674== LEAK SUMMARY:
==31674== definitely lost: 320 bytes in 20 blocks
==31674== indirectly lost: 0 bytes in 0 blocks
==31674== possibly lost: 0 bytes in 0 blocks
==31674== still reachable: 8 bytes in 1 blocks
==31674== suppressed: 0 bytes in 0 blocks
==31674==
==31674== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
--31674--
--31674-- used_suppression: 2 dl-hack3-cond-1
==31674==
==31674== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
It's your errors, not boost::threads.
Your memory are not freed.
for (i = 0; i < THREADS; i++) {
threads[i] = new boost::thread(threadfunc, i);
}
Before exit from main function you must free memory (delete threads).
Something like
for (i = 0; i < THREADS; i++) {
delete threads[i];
}
or delete next after join.
==11136== Invalid read of size 8
==11136== at 0x5AFC696: memrchr (memrchr.S:289)
==11136== by 0x5B57FAF: dirname (dirname.c:45)
==11136== by 0x405F43: push::lg_cmd_dirname(push::Env&) (LGExtension.cpp:379)
==11136== by 0x42533C: push::Instruction::operator()(push::Env&) const (in /home/bots/svn/eco/branches/skynet_BigPUSH/src/push3.0/extension/push_bloodline)
==11136== by 0x488ECD: push::Env::go(int) (Env.cpp:72)
==11136== by 0x4A84D5: main (bloodline.cpp:99)
==11136== Address 0x640daf8 is 8 bytes inside a block of size 10 alloc'd
==11136== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11136== by 0x5AEF801: strdup (strdup.c:43)
==11136== by 0x405EF2: push::lg_cmd_dirname(push::Env&) (LGExtension.cpp:369)
==11136== by 0x42533C: push::Instruction::operator()(push::Env&) const (in /home/bots/svn/eco/branches/skynet_BigPUSH/src/push3.0/extension/push_bloodline)
==11136== by 0x488ECD: push::Env::go(int) (Env.cpp:72)
==11136== by 0x4A84D5: main (bloodline.cpp:99)
==11136==
Is this a legitimate error? It looks like the read takes place inside a valid block. In my program, the call looks like this:
char *path = strdup(full_path.c_str());
cerr << "Path is : " << path << endl;
result = dirname(path);
if(result < 0){
cerr << "Dirname failed for some reason. Check log." << endl;
}
and the output to cerr at the time of the error is:
Path is : /tmp/tmp/
which is a valid path. Dirname shouldn't have any trouble with this, and it's operating on a heap allocated duplicate.
EDIT:
Here is a minimal example that will produce this error:
#include <string.h>
#include <stdio.h>
#include <iostream>
#include <libgen.h>
int main(){
char *path = strdup("/tmp/tmp/");
char* result = dirname(path);
std::cerr << result << std::endl;
}
compile with g++.
run with valgrind, and you get:
==32466== Memcheck, a memory error detector
==32466== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==32466== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==32466== Command: ./a.out
==32466==
==32466== Invalid read of size 8
==32466== at 0x51C7696: memrchr (memrchr.S:289)
==32466== by 0x5222FAF: dirname (dirname.c:45)
==32466== by 0x400865: main (in /home/j3doucet/a.out)
==32466== Address 0x59ff048 is 8 bytes inside a block of size 10 alloc'd
==32466== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32466== by 0x51BA801: strdup (strdup.c:43)
==32466== by 0x400855: main (in /home/j3doucet/a.out)
==32466==
/tmp
==32466==
==32466== HEAP SUMMARY:
==32466== in use at exit: 10 bytes in 1 blocks
==32466== total heap usage: 1 allocs, 0 frees, 10 bytes allocated
==32466==
==32466== LEAK SUMMARY:
==32466== definitely lost: 10 bytes in 1 blocks
==32466== indirectly lost: 0 bytes in 0 blocks
==32466== possibly lost: 0 bytes in 0 blocks
==32466== still reachable: 0 bytes in 0 blocks
==32466== suppressed: 0 bytes in 0 blocks
==32466== Rerun with --leak-check=full to see details of leaked memory
==32466==
==32466== For counts of detected and suppressed errors, rerun with: -v
==32466== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
Valgrind indicates that a read of size 8 is done from the byte nr 8 in
a block of 10 bytes.
This read is done by memrchr.
Such functions are often optimised based on the assumption that you can read
more bytes than the allocated block.
To avoid reporting such problems, Valgrind has to replace such optimised
functions by its own redefining function.
memrchr has only been redefined in Valgrind from version 3.8 onwards.
=> you should retry with the latest version of Valgrind (3.8.1).
Error might then not be reported anymore (assuming it is effectively a false positive
due to non redefinition of memrchr).
I am wondering if the size of float and double objects are equal from std::list point of view?
I've allocated 5-million Real(alias float or double) objects in a std::list and used Valgrind to monitor memory usage.
in both cases the used memory is equal although the size of a 'double' (8 bytes) is double the size if a 'float' object (4 bytes)!
Btw, when I allocate memory for the same amount of objects using 'new' operator, the memory usage of the double array is double the usage of the float array, which seems about right. I was expecting the same using std::list too.
I am using gcc 4.6.2, on Fedora 16.x86_64.
Any idea to help me figure the mystery is appreciated.
here is the code I wrote for test
#include <iostream>
#include <list>
typedef double Real;
int main(int argc, char** argv)
{
std::list<Real> pts;
int k;
int npts = 5000000; // 5 mil
std::cout << "sizeof(Real): " << sizeof(Real) << std::endl;
for(k=0; k < npts;++k)
pts.push_back(1.0);
return 0;
}
if I define Real <- double the Valgrind output is
==15335== Memcheck, a memory error detector
==15335== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==15335== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==15335== Command: /home/soheil/Workspace/tbin/test_memory_usage
==15335==
sizeof(Real): 8
==15335==
==15335== HEAP SUMMARY:
==15335== in use at exit: 616 bytes in 6 blocks
==15335== total heap usage: 5,000,053 allocs, 5,000,047 frees, 120,015,245 bytes allocated
==15335==
==15335== LEAK SUMMARY:
==15335== definitely lost: 0 bytes in 0 blocks
==15335== indirectly lost: 0 bytes in 0 blocks
==15335== possibly lost: 0 bytes in 0 blocks
==15335== still reachable: 616 bytes in 6 blocks
==15335== suppressed: 0 bytes in 0 blocks
==15335== Rerun with --leak-check=full to see details of leaked memory
==15335==
==15335== For counts of detected and suppressed errors, rerun with: -v
==15335== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
if I define Real <- float the Valgrind output is
==15252== Memcheck, a memory error detector
==15252== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==15252== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==15252== Command: /home/soheil/Workspace/tbin/test_memory_usage
==15252==
sizeof(Real): 4
==15252==
==15252== HEAP SUMMARY:
==15252== in use at exit: 616 bytes in 6 blocks
==15252== total heap usage: 5,000,053 allocs, 5,000,047 frees, 120,015,245 bytes allocated
==15252==
==15252== LEAK SUMMARY:
==15252== definitely lost: 0 bytes in 0 blocks
==15252== indirectly lost: 0 bytes in 0 blocks
==15252== possibly lost: 0 bytes in 0 blocks
==15252== still reachable: 616 bytes in 6 blocks
==15252== suppressed: 0 bytes in 0 blocks
==15252== Rerun with --leak-check=full to see details of leaked memory
==15252==
==15252== For counts of detected and suppressed errors, rerun with: -v
==15252== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
Each element in a std::list<T> is a linked-list node, so it's a struct containing two pointers, as well as the payload data of type T. For instance, for GCC 4.1.2, it's as follows:
struct _List_node_base
{
_List_node_base* _M_next;
_List_node_base* _M_prev;
// *** Non-virtual member functions ***
};
template<typename _Tp>
struct _List_node : public _List_node_base
{
_Tp _M_data;
};
The size allocated will be the size of that struct; if T is small enough then you may be seeing the figures dominated by struct padding.
So with the GCC definition, that's two 64-bit pointers (so 16 bytes), plus 4 or 8 bytes T, padded up to 8 bytes, so 24 bytes in total, which matches what you're measuring.
To test the theory, try changing Real to be float[2] or double[2].