I get a seg-fault applying valgrind to a very simple MPI program:
#include "mpi.h"
#include <iostream>
#include<stdio.h>
#include<stdlib.h>
int main(int argc, char *argv[])
{
// Initialize parallel
int rank, numProcess;
MPI_Status status;
MPI_Init(&argc, &argv);
MPI_Comm_rank(MPI_COMM_WORLD, &rank);
MPI_Comm_size(MPI_COMM_WORLD, &numProcess);
std::cout << "Hello world, - Rank " << rank << "\n";
MPI_Finalize();
return 0;
}
Calling mpirun -np 2 ./mpi_test works as expected. However, mpirun -np 2 valgrind ./mpi_test returns a long list of errors and does not say Hello world. I am aware that valgrind can detect false positives in MPI, but here it will not even run a simple hello world program. Below is the errors I get.
==85595== Memcheck, a memory error detector
==85595== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==85595== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==85595== Command: ./mpi_test
==85595==
==85596== Memcheck, a memory error detector
==85596== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==85596== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==85596== Command: ./mpi_test
==85596==
==85596== Syscall param msg->desc.port.name points to uninitialised byte(s)
==85596== at 0x10070B34A: mach_msg_trap (in /usr/lib/system/libsystem_kernel.dylib)
==85596== by 0x10070A796: mach_msg (in /usr/lib/system/libsystem_kernel.dylib)
==85596== by 0x100704485: task_set_special_port (in /usr/lib/system/libsystem_kernel.dylib)
==85596== by 0x1008A010E: _os_trace_create_debug_control_port (in /usr/lib/system/libsystem_trace.dylib)
==85596== by 0x1008A0458: _libtrace_init (in /usr/lib/system/libsystem_trace.dylib)
==85596== by 0x10026B9DF: libSystem_initializer (in /usr/lib/libSystem.B.dylib)
==85596== by 0x10001AA1A: ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==85596== by 0x10001AC1D: ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==85596== by 0x1000164A9: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld)
==85596== by 0x100016440: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld)
==85596== by 0x100015523: ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld)
==85596== by 0x1000155B8: ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) (in /usr/lib/dyld)
==85596== Address 0x10488d25c is on thread 1's stack
==85596== in frame #2, created by task_set_special_port (???:)
==85596==
==85595== Syscall param msg->desc.port.name points to uninitialised byte(s)
==85595== at 0x10070B34A: mach_msg_trap (in /usr/lib/system/libsystem_kernel.dylib)
==85595== by 0x10070A796: mach_msg (in /usr/lib/system/libsystem_kernel.dylib)
==85595== by 0x100704485: task_set_special_port (in /usr/lib/system/libsystem_kernel.dylib)
==85595== by 0x1008A010E: _os_trace_create_debug_control_port (in /usr/lib/system/libsystem_trace.dylib)
==85595== by 0x1008A0458: _libtrace_init (in /usr/lib/system/libsystem_trace.dylib)
==85595== by 0x10026B9DF: libSystem_initializer (in /usr/lib/libSystem.B.dylib)
==85595== by 0x10001AA1A: ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==85595== by 0x10001AC1D: ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==85595== by 0x1000164A9: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld)
==85595== by 0x100016440: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld)
==85595== by 0x100015523: ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld)
==85595== by 0x1000155B8: ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) (in /usr/lib/dyld)
==85595== Address 0x10488d25c is on thread 1's stack
==85595== in frame #2, created by task_set_special_port (???:)
==85595==
--85595-- UNKNOWN task message [id 3445, to mach_task_self(), reply 0x707]
--85596-- UNKNOWN task message [id 3445, to mach_task_self(), reply 0x707]
--85595-- UNKNOWN task message [id 3445, to mach_task_self(), reply 0x707] (repeated 2 times)
--85596-- UNKNOWN task message [id 3445, to mach_task_self(), reply 0x707] (repeated 2 times)
--85596-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option
--85595-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option
--85596-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times)
--85595-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times)
--85596-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times)
--85595-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times)
--85595-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 8 times)
--85596-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 8 times)
==85595== Thread 2:
==85595== Invalid read of size 4
==85595== at 0x100868899: _pthread_body (in /usr/lib/system/libsystem_pthread.dylib)
==85595== by 0x100868886: _pthread_start (in /usr/lib/system/libsystem_pthread.dylib)
==85595== by 0x10086808C: thread_start (in /usr/lib/system/libsystem_pthread.dylib)
==85595== Address 0x18 is not stack'd, malloc'd or (recently) free'd
==85595==
==85595== Invalid read of size 8
==85595== at 0x100866435: _pthread_mutex_lock_slow (in /usr/lib/system/libsystem_pthread.dylib)
==85595== by 0x100560117: dyldGlobalLockAcquire() (in /usr/lib/system/libdyld.dylib)
==85595== by 0x100021F95: ImageLoaderMachOCompressed::doBindFastLazySymbol(unsigned int, ImageLoader::LinkContext const&, void (*)(), void (*)()) (in /usr/lib/dyld)
==85595== by 0x10000986C: dyld::fastBindLazySymbol(ImageLoader**, unsigned long) (in /usr/lib/dyld)
==85595== by 0x100560281: dyld_stub_binder (in /usr/lib/system/libdyld.dylib)
==85595== by 0x100382977: ??? (in /usr/local/Cellar/open-mpi/3.0.0_2/lib/libopen-pal.40.dylib)
==85595== by 0x25805BBB1: ???
==85595== by 0x100868886: _pthread_start (in /usr/lib/system/libsystem_pthread.dylib)
==85595== by 0x10086808C: thread_start (in /usr/lib/system/libsystem_pthread.dylib)
==85595== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==85595==
==85595==
==85595== Process terminating with default action of signal 11 (SIGSEGV)
==85595== Access not within mapped region at address 0x0
==85595== at 0x100866435: _pthread_mutex_lock_slow (in /usr/lib/system/libsystem_pthread.dylib)
==85595== by 0x100560117: dyldGlobalLockAcquire() (in /usr/lib/system/libdyld.dylib)
==85595== by 0x100021F95: ImageLoaderMachOCompressed::doBindFastLazySymbol(unsigned int, ImageLoader::LinkContext const&, void (*)(), void (*)()) (in /usr/lib/dyld)
==85595== by 0x10000986C: dyld::fastBindLazySymbol(ImageLoader**, unsigned long) (in /usr/lib/dyld)
==85595== by 0x100560281: dyld_stub_binder (in /usr/lib/system/libdyld.dylib)
==85595== by 0x100382977: ??? (in /usr/local/Cellar/open-mpi/3.0.0_2/lib/libopen-pal.40.dylib)
==85595== by 0x25805BBB1: ???
==85595== by 0x100868886: _pthread_start (in /usr/lib/system/libsystem_pthread.dylib)
==85595== by 0x10086808C: thread_start (in /usr/lib/system/libsystem_pthread.dylib)
==85595== If you believe this happened as a result of a stack
==85595== overflow in your program's main thread (unlikely but
==85595== possible), you can try to increase the size of the
==85595== main thread stack using the --main-stacksize= flag.
==85595== The main thread stack size used in this run was 8388608.
--85595:0:schedule VG_(sema_down): read returned -4
==85595==
==85595== HEAP SUMMARY:
==85595== in use at exit: 358,368 bytes in 3,295 blocks
==85595== total heap usage: 5,625 allocs, 2,330 frees, 721,547 bytes allocated
==85595==
==85596== Thread 2:
==85596== Invalid read of size 4
==85596== at 0x100868899: _pthread_body (in /usr/lib/system/libsystem_pthread.dylib)
==85596== by 0x100868886: _pthread_start (in /usr/lib/system/libsystem_pthread.dylib)
==85596== by 0x10086808C: thread_start (in /usr/lib/system/libsystem_pthread.dylib)
==85596== Address 0x18 is not stack'd, malloc'd or (recently) free'd
==85596==
==85596== Invalid read of size 8
==85596== at 0x100866435: _pthread_mutex_lock_slow (in /usr/lib/system/libsystem_pthread.dylib)
==85596== by 0x100560117: dyldGlobalLockAcquire() (in /usr/lib/system/libdyld.dylib)
==85596== by 0x100021F95: ImageLoaderMachOCompressed::doBindFastLazySymbol(unsigned int, ImageLoader::LinkContext const&, void (*)(), void (*)()) (in /usr/lib/dyld)
==85596== by 0x10000986C: dyld::fastBindLazySymbol(ImageLoader**, unsigned long) (in /usr/lib/dyld)
==85596== by 0x100560281: dyld_stub_binder (in /usr/lib/system/libdyld.dylib)
==85596== by 0x100382977: ??? (in /usr/local/Cellar/open-mpi/3.0.0_2/lib/libopen-pal.40.dylib)
==85596== by 0x25805BBB1: ???
==85596== by 0x100868886: _pthread_start (in /usr/lib/system/libsystem_pthread.dylib)
==85596== by 0x10086808C: thread_start (in /usr/lib/system/libsystem_pthread.dylib)
==85596== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==85596==
==85596==
==85596== Process terminating with default action of signal 11 (SIGSEGV)
==85596== Access not within mapped region at address 0x0
==85596== at 0x100866435: _pthread_mutex_lock_slow (in /usr/lib/system/libsystem_pthread.dylib)
==85596== by 0x100560117: dyldGlobalLockAcquire() (in /usr/lib/system/libdyld.dylib)
==85596== by 0x100021F95: ImageLoaderMachOCompressed::doBindFastLazySymbol(unsigned int, ImageLoader::LinkContext const&, void (*)(), void (*)()) (in /usr/lib/dyld)
==85596== by 0x10000986C: dyld::fastBindLazySymbol(ImageLoader**, unsigned long) (in /usr/lib/dyld)
==85596== by 0x100560281: dyld_stub_binder (in /usr/lib/system/libdyld.dylib)
==85596== by 0x100382977: ??? (in /usr/local/Cellar/open-mpi/3.0.0_2/lib/libopen-pal.40.dylib)
==85596== by 0x25805BBB1: ???
==85596== by 0x100868886: _pthread_start (in /usr/lib/system/libsystem_pthread.dylib)
==85596== by 0x10086808C: thread_start (in /usr/lib/system/libsystem_pthread.dylib)
==85596== If you believe this happened as a result of a stack
==85596== overflow in your program's main thread (unlikely but
==85596== possible), you can try to increase the size of the
==85596== main thread stack using the --main-stacksize= flag.
==85596== The main thread stack size used in this run was 8388608.
--85596:0:schedule VG_(sema_down): read returned -4
==85596==
==85596== HEAP SUMMARY:
==85596== in use at exit: 358,368 bytes in 3,295 blocks
==85596== total heap usage: 5,625 allocs, 2,330 frees, 721,547 bytes allocated
==85596==
==85595== LEAK SUMMARY:
==85595== definitely lost: 9,159 bytes in 47 blocks
==85595== indirectly lost: 8,112 bytes in 111 blocks
==85595== possibly lost: 0 bytes in 0 blocks
==85595== still reachable: 325,270 bytes in 2,982 blocks
==85595== suppressed: 15,827 bytes in 155 blocks
==85595== Rerun with --leak-check=full to see details of leaked memory
==85595==
==85595== For counts of detected and suppressed errors, rerun with: -v
==85595== Use --track-origins=yes to see where uninitialised values come from
==85595== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 1 from 1)
==85596== LEAK SUMMARY:
==85596== definitely lost: 3,839 bytes in 1 blocks
==85596== indirectly lost: 0 bytes in 0 blocks
==85596== possibly lost: 72 bytes in 3 blocks
==85596== still reachable: 336,638 bytes in 3,138 blocks
==85596== suppressed: 17,819 bytes in 153 blocks
==85596== Rerun with --leak-check=full to see details of leaked memory
==85596==
==85596== For counts of detected and suppressed errors, rerun with: -v
==85596== Use --track-origins=yes to see where uninitialised values come from
==85596== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 1 from 1)
-------------------------------------------------------
Primary job terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
-------------------------------------------------------
--------------------------------------------------------------------------
mpirun noticed that process rank 0 with PID 0 on node cu-vpn-colorado-edu-198 exited on signal 11 (Segmentation fault: 11).
--------------------------------------------------------------------------
I would be suspecting that there is something up with Valgrind and possible your OS.
As I can compile and run your program without any issues on Linux:
tb-xps ../tmp$ mpicxx -o h2 h2.cpp
tb-xps ../tmp$ mpirun -n 1 ./h2
Hello world, - Rank 0
tb-xps ../tmp$ mpirun -n 1 valgrind ./h2
==3544== Memcheck, a memory error detector
==3544== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==3544== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==3544== Command: ./h2
==3544==
==3544== Thread 3:
==3544== Syscall param epoll_pwait(sigmask) points to unaddressable byte(s)
==3544== at 0x5F5AFE6: epoll_pwait (in /usr/lib/libc-2.26.so)
==3544== by 0x6536DDC: ??? (in /usr/lib/openmpi/libopen-pal.so.40.0.0)
==3544== by 0x653AEDA: opal_libevent2022_event_base_loop (in /usr/lib/openmpi/libopen-pal.so.40.0.0)
==3544== by 0x90CA0CE: ??? (in /usr/lib/openmpi/openmpi/mca_pmix_pmix2x.so)
==3544== by 0x5C4E08B: start_thread (in /usr/lib/libpthread-2.26.so)
==3544== by 0x5F5AE7E: clone (in /usr/lib/libc-2.26.so)
==3544== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==3544==
Hello world, - Rank 0
==3544==
==3544== HEAP SUMMARY:
==3544== in use at exit: 1,899 bytes in 44 blocks
==3544== total heap usage: 17,910 allocs, 17,866 frees, 3,993,061 bytes allocated
==3544==
==3544== LEAK SUMMARY:
==3544== definitely lost: 372 bytes in 4 blocks
==3544== indirectly lost: 1,288 bytes in 34 blocks
==3544== possibly lost: 0 bytes in 0 blocks
==3544== still reachable: 239 bytes in 6 blocks
==3544== suppressed: 0 bytes in 0 blocks
==3544== Rerun with --leak-check=full to see details of leaked memory
==3544==
==3544== For counts of detected and suppressed errors, rerun with: -v
==3544== ERROR SUMMARY: 39 errors from 1 contexts (suppressed: 0 from 0)
tb-xps ../tmp$ uname -a
Linux tb-xps 4.15.3-1-ARCH #1 SMP PREEMPT Mon Feb 12 23:01:17 UTC 2018 x86_64 GNU/Linux
Also since I am not a C++ programmer, I'd get rid of the iostream and just use printf, I'd also re-arrange my includes and add some white-spaces:
#include <stdio.h>
#include <stdlib.h>
#include <mpi.h>
Do you have access to a different machine? Are you able to ask a Valgrind mailing list?
Related
I have the following problem: recently I was trying to improve the performance of my programs using this option:
std::ios_base::sync_with_stdio( false );
which I read from here that it is useful to increase the output stream speed for std::cout.
The problem is that, if I try to compile my program prove.cpp with g++ and -std=c++17 flag:
#include <ios>
class foo
{
public:
void test() { std::ios_base::sync_with_stdio( false );}
};
int main
{
foo object;
object.test();
}
and run Valgrind memcheck tool on the executable, using:
valgrind --leak-check=full --show-leak-kinds=all ./a.out
I got a sort of error from Valgrind output:
==353686== Memcheck, a memory error detector
==353686== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==353686== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==353686== Command: ./a.out
==353686==
==353686==
==353686== HEAP SUMMARY:
==353686== in use at exit: 122,880 bytes in 6 blocks
==353686== total heap usage: 7 allocs, 1 frees, 195,584 bytes allocated
==353686==
==353686== 8,192 bytes in 1 blocks are still reachable in loss record 1 of 6
==353686== at 0x483C583: operator new[](unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==353686== by 0x4977D03: std::basic_filebuf<char, std::char_traits<char> >::_M_allocate_internal_buffer() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686== by 0x4975AD9: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686== by 0x4927AA7: std::ios_base::sync_with_stdio(bool) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686== by 0x10926B: foo::test() (in /home/gianluca/a.out)
==353686== by 0x1091CF: main (in /home/gianluca/a.out)
==353686==
==353686== 8,192 bytes in 1 blocks are still reachable in loss record 2 of 6
==353686== at 0x483C583: operator new[](unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==353686== by 0x4977D03: std::basic_filebuf<char, std::char_traits<char> >::_M_allocate_internal_buffer() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686== by 0x4975AD9: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686== by 0x4927AC8: std::ios_base::sync_with_stdio(bool) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686== by 0x10926B: foo::test() (in /home/gianluca/a.out)
==353686== by 0x1091CF: main (in /home/gianluca/a.out)
==353686==
==353686== 8,192 bytes in 1 blocks are still reachable in loss record 3 of 6
==353686== at 0x483C583: operator new[](unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==353686== by 0x4977D03: std::basic_filebuf<char, std::char_traits<char> >::_M_allocate_internal_buffer() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686== by 0x4975AD9: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686== by 0x4927AE8: std::ios_base::sync_with_stdio(bool) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686== by 0x10926B: foo::test() (in /home/gianluca/a.out)
==353686== by 0x1091CF: main (in /home/gianluca/a.out)
==353686==
==353686== 32,768 bytes in 1 blocks are still reachable in loss record 4 of 6
==353686== at 0x483C583: operator new[](unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==353686== by 0x4979B16: std::basic_filebuf<wchar_t, std::char_traits<wchar_t> >::_M_allocate_internal_buffer() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686== by 0x4975CC9: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686== by 0x4927B5D: std::ios_base::sync_with_stdio(bool) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686== by 0x10926B: foo::test() (in /home/gianluca/a.out)
==353686== by 0x1091CF: main (in /home/gianluca/a.out)
==353686==
==353686== 32,768 bytes in 1 blocks are still reachable in loss record 5 of 6
==353686== at 0x483C583: operator new[](unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==353686== by 0x4979B16: std::basic_filebuf<wchar_t, std::char_traits<wchar_t> >::_M_allocate_internal_buffer() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686== by 0x4975CC9: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686== by 0x4927B77: std::ios_base::sync_with_stdio(bool) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686== by 0x10926B: foo::test() (in /home/gianluca/a.out)
==353686== by 0x1091CF: main (in /home/gianluca/a.out)
==353686==
==353686== 32,768 bytes in 1 blocks are still reachable in loss record 6 of 6
==353686== at 0x483C583: operator new[](unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==353686== by 0x4979B16: std::basic_filebuf<wchar_t, std::char_traits<wchar_t> >::_M_allocate_internal_buffer() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686== by 0x4975CC9: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686== by 0x4927B90: std::ios_base::sync_with_stdio(bool) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==353686== by 0x10926B: foo::test() (in /home/gianluca/a.out)
==353686== by 0x1091CF: main (in /home/gianluca/a.out)
==353686==
==353686== LEAK SUMMARY:
==353686== definitely lost: 0 bytes in 0 blocks
==353686== indirectly lost: 0 bytes in 0 blocks
==353686== possibly lost: 0 bytes in 0 blocks
==353686== still reachable: 122,880 bytes in 6 blocks
==353686== suppressed: 0 bytes in 0 blocks
==353686==
==353686== For lists of detected and suppressed errors, rerun with: -s
==353686== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Do you know how to solve it? Should I suppress it? Thanks.
Based on other's answers, it seems that there is no easy solution to the problem. However, since this is a not so relevant issue and memory is reclaimed when my program exits, I concluded that the most suitable "solution" is to add these specific errors to a Valgrind suppression file.
I must edit the complex code that is written with Fortran. Actually, I do not have good knowledge about Fortran. So in this post, I hope receive your help.
In this code, someone declare variables by header file-commonkb.h :
common/cntrl2/SWNU,BB6(500,500)
real*8 SWNU,BB6
when I run:
valgrind --tool=memcheck --leak-check=full --log-file=log ./main
I have the error:
==4026== Memcheck, a memory error detector
==4026== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==4026== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==4026== Command: ./main
==4026== Parent PID: 3252
==4026==
==4026== Warning: set address range perms: large range [0x324000, 0x28499000) (defined)
==4026==
==4026== HEAP SUMMARY:
==4026== in use at exit: 1,072 bytes in 4 blocks
==4026== total heap usage: 10,875 allocs, 10,871 frees, 733,306 bytes allocated
==4026==
==4026== 536 (24 direct, 512 indirect) bytes in 1 blocks are definitely lost in loss record 3 of 4
==4026== at 0x290C8B0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4026== by 0x292EF7F4: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.4.0.0)
==4026== by 0x29474D25: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.4.0.0)
==4026== by 0x2946C3B9: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.4.0.0)
==4026== by 0x292EE867: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.4.0.0)
==4026== by 0x284A9732: call_init (dl-init.c:72)
==4026== by 0x284A9732: _dl_init (dl-init.c:119)
==4026== by 0x2849A0C9: ??? (in /lib/x86_64-linux-gnu/ld-2.27.so)
==4026==
==4026== 536 (24 direct, 512 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 4
==4026== at 0x290C8B0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4026== by 0x292EF7F4: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.4.0.0)
==4026== by 0x29474D25: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.4.0.0)
==4026== by 0x2946C48B: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.4.0.0)
==4026== by 0x292EE867: ??? (in /usr/lib/x86_64-linux-gnu/libgfortran.so.4.0.0)
==4026== by 0x284A9732: call_init (dl-init.c:72)
==4026== by 0x284A9732: _dl_init (dl-init.c:119)
==4026== by 0x2849A0C9: ??? (in /lib/x86_64-linux-gnu/ld-2.27.so)
==4026==
==4026== LEAK SUMMARY:
==4026== definitely lost: 48 bytes in 2 blocks
==4026== indirectly lost: 1,024 bytes in 2 blocks
==4026== possibly lost: 0 bytes in 0 blocks
==4026== still reachable: 0 bytes in 0 blocks
==4026== suppressed: 0 bytes in 0 blocks
==4026==
==4026== For counts of detected and suppressed errors, rerun with: -v
==4026== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
How can I solve this problem?
Thank you for your help.
Valgring doesn`t detect memory errors.
I am using valgrind 3.11, gcc 5.4.0 under ubuntu and
have an incorrect code in my program, like in the sample.
I analyzed this program, using valgrind. But valgrind doesn't report about any errors.
#include <string.h>
int main(){
int a[3];
memcpy(a,"aaabbbcccdddeeefffggghhh", 24);
return 0;
}
What's wrong with valgrind?
valgrind doesn't know a, not its size then, while you stay in the stack it cannot detect the error
To compare, having that :
#include <string.h>
int main(){
int * a = new int[3];
memcpy(a,"aaabbbcccdddeeefffggghhh", 24);
return 0;
}
valgrind can detect the error because it knows the size of the allocated block :
pi#raspberrypi:/tmp $ valgrind ./a.out
==16164== Memcheck, a memory error detector
==16164== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==16164== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==16164== Command: ./a.out
==16164==
==16164== Invalid write of size 8
==16164== at 0x4865F44: ??? (in /usr/lib/arm-linux-gnueabihf/libarmmem.so)
==16164== Address 0x4bc9f60 is 8 bytes inside a block of size 12 alloc'd
==16164== at 0x48485F0: operator new[](unsigned int) (vg_replace_malloc.c:417)
==16164== by 0x105A7: main (v.cc:3)
==16164==
==16164== Invalid write of size 8
==16164== at 0x4865F54: ??? (in /usr/lib/arm-linux-gnueabihf/libarmmem.so)
==16164== Address 0x4bc9f68 is 4 bytes after a block of size 12 alloc'd
==16164== at 0x48485F0: operator new[](unsigned int) (vg_replace_malloc.c:417)
==16164== by 0x105A7: main (v.cc:3)
==16164==
==16164==
==16164== HEAP SUMMARY:
==16164== in use at exit: 12 bytes in 1 blocks
==16164== total heap usage: 2 allocs, 1 frees, 20,236 bytes allocated
==16164==
==16164== LEAK SUMMARY:
==16164== definitely lost: 12 bytes in 1 blocks
==16164== indirectly lost: 0 bytes in 0 blocks
==16164== possibly lost: 0 bytes in 0 blocks
==16164== still reachable: 0 bytes in 0 blocks
==16164== suppressed: 0 bytes in 0 blocks
==16164== Rerun with --leak-check=full to see details of leaked memory
==16164==
==16164== For counts of detected and suppressed errors, rerun with: -v
==16164== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 6 from 3)
I'm actually developping a game in C++ and trying to do the AI with a script langage. To do so, i choosed Python2 with Python/C api.
My AI is actually working but there is a big problem : when I run valgrind on my program, there is a lot of error and memory leaks. So, I would know if this happened because of my code or by the API ?
Here is a summary of my class AI :
IA::IA()
{
setenv("PYTHONPATH",".",1);
Py_Initialize();
PyRun_SimpleString("import sys");
pName = PyBytes_FromString((char*)"Test");
pModule = PyImport_Import(pName);
pDict = PyModule_GetDict(pModule);
pFunc = PyDict_GetItemString(pDict, "push_f");
}
IA::~IA()
{
Py_DECREF(pValue);
Py_DECREF(pModule);
Py_DECREF(pName);
Py_Finalize();
}
void IA::LaunchIA(float x, float y, float z)
{
PyObject *toSend;
toSend = Py_BuildValue("(OOO)", TlistMob, TlistPlayer, pDPosIA);
pResult = PyObject_CallObject(pFunc, toSend);
PyErr_Print();
printf("return = %f\n", (float)PyInt_AsLong(pResult));
}
My (very) simple Python code :
def push_f(MobList, PlayerList, pos):
return 0
And the valgrind error (x1000) :
==11602== Memcheck, a memory error detector
==11602== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==11602== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==11602== Command: ./a.out
==11602==
==11602== Invalid read of size 4
==11602== at 0x4FCE173: PyObject_Free (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x4F02FC2: ??? (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x4FBDE9A: ??? (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x4F85BAD: ??? (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x4F872FF: ??? (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x4F88559: PyImport_ImportModuleLevel (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x4EFF697: ??? (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x4F4B1E2: PyObject_Call (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x5021446: PyEval_CallObjectWithKeywords (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x4EF45C5: PyEval_EvalFrameEx (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x502201B: PyEval_EvalCodeEx (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x4EF0B88: PyEval_EvalCode (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== Address 0x693c020 is 2,560 bytes inside a block of size 2,731 free'd
==11602== at 0x4C2EDEB: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11602== by 0x4F81D28: PyMarshal_ReadLastObjectFromFile (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x4F85A22: ??? (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x4F872FF: ??? (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x4F88559: PyImport_ImportModuleLevel (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x4EFF697: ??? (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x4F4B1E2: PyObject_Call (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x5021446: PyEval_CallObjectWithKeywords (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x4EF45C5: PyEval_EvalFrameEx (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x502201B: PyEval_EvalCodeEx (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x4EF0B88: PyEval_EvalCode (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x4F851B3: PyImport_ExecCodeModuleEx (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== Block was alloc'd at
==11602== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11602== by 0x4F81CDF: PyMarshal_ReadLastObjectFromFile (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x4F85A22: ??? (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x4F872FF: ??? (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x4F88559: PyImport_ImportModuleLevel (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x4EFF697: ??? (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x4F4B1E2: PyObject_Call (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x5021446: PyEval_CallObjectWithKeywords (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x4EF45C5: PyEval_EvalFrameEx (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x502201B: PyEval_EvalCodeEx (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x4EF0B88: PyEval_EvalCode (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602== by 0x4F851B3: PyImport_ExecCodeModuleEx (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11602==
==11602==
==11602== HEAP SUMMARY:
==11602== in use at exit: 491,741 bytes in 204 blocks
==11602== total heap usage: 3,301 allocs, 3,097 frees, 3,567,424 bytes allocated
==11602==
==11602== LEAK SUMMARY:
==11602== definitely lost: 0 bytes in 0 blocks
==11602== indirectly lost: 0 bytes in 0 blocks
==11602== possibly lost: 1,072 bytes in 2 blocks
==11602== still reachable: 490,669 bytes in 202 blocks
==11602== suppressed: 0 bytes in 0 blocks
==11602== Rerun with --leak-check=full to see details of leaked memory
==11602==
==11602== For counts of detected and suppressed errors, rerun with: -v
==11602== Use --track-origins=yes to see where uninitialised values come from
==11602== ERROR SUMMARY: 497 errors from 25 contexts (suppressed: 0 from 0)
In my main, you need to know that I'm creating only one IA object.
Am I doing something wrong ? Or is it just the API ?
(This is not a duplicate because I run valgrind on my C++ executable and not Python, my c++ is running the script)
Thanks in advance !!!
I initially suggested this as a duplicate. I don't think that's the case any more, but it still gives useful advice on removing false positives from the Valgrind output for Python programs.
Beyond that there are a number of specific issues with your program:
No error checking - the Python C API typically uses a NULL return value to indicate an error. There are clearly various ways of writing error checking code, but I'd be tempted to go for something like
IA::IA() :
pModule(NULL), pDict(NULL), pFunc(NULL), pName(NULL) // initially null initialize everything
{
setenv("PYTHONPATH",".",1);
Py_Initialize();
// I don't think you actually use this line, so maybe remove it
if (PyRun_SimpleString("import sys") == -1) goto error;
pName = PyBytes_FromString((char*)"Test");
if (!pName) goto error;
pModule = PyImport_Import(pName);
if (!pModule) goto error;
pDict = PyModule_GetDict(pModule);
if (!pDict) goto error;
pFunc = PyDict_GetItemString(pDict, "push_f");
if (!pFunc) goto error;
return; // completed OK
error:
Py_XDECREF(pName); // XDECREF is OK with NULL...
Py_XDECREF(pModule);
Py_XDECREF(pDict);
Py_XDECREF(pFunc);
PyErr_Print();
throw std::runtime_error(""); // ??? - possibly get and use the error string
// see https://stackoverflow.com/a/1418703/4657412
}
I'm aware people are suspicious of goto but in this case it's a reasonably clean way of jumping to an error handling block. You can structure it differently if you like.
The destructor doesn't decref pFunc, which looks like a memory leak.
IA::LaunchIA similarly is lacking working error checking.
IA::LaunchIA never decrefs toSend, pResult, TlistMob, TlistPlayer, pDPosIA. Some of these are related to the incompleteness of the code you show, but if they aren't decrefed then you're leaking memory.
You call PyErr_Print() without checking for an error. The documentation says:
Call this function only when the error indicator is set. (Otherwise it will cause a fatal error!)
I suspect that this might be your biggest problem.
Those are all the issues I can see. Without a minimal complete example it's impossible to actually check what you're seeing. Given you're using C++ you might be well advised to use/make a decent, object oriented wrapper for PyObject* to avoid having to worry about reference counting yourself - Boost Python has one.
I have a CPP code which uses openmp. It is linked to a fortran90 code. If run with one thread, everything is fine. If run with any number of threads different from 1, I get a segmentation fault when exiting the cpp part. The result of the code is exact, no errors whatsoever. It runs smoothly, until it's time to exit. The part of the code related to openmp is:
#pragma omp parallel for shared(even_phi,odd_phi,odd_divisor,odd_start_index,odd_iter_index) private(ii,jj,kk,cc,io,pp,f1,f2,f3,f4,f5,f6,ff,tmp_phi) schedule(static)
for (kk=1; kk<nz-1; kk++)
{
cc = (kk-1)*(ny-2);
for (jj=1; jj<ny-1; jj++)
{
io = odd_start_index[cc];
pp = odd_iter_index[cc++];
for (ii=io; ii<maxElem; ii++)
{
f1 = even_phi[pp-odown];
f2 = even_phi[pp-oright];
f3 = even_phi[pp];
tmp_phi = odd_phi[pp];
f4 = even_phi[pp+1];
f5 = even_phi[pp+oleft];
f6 = even_phi[pp+oup];
ff = f1+f2+f3+f4+f5+f6;
odd_phi[pp] = odd_divisor[pp]*ff + c2*tmp_phi;
pp++;
}
}
}
it's a standard numerical solver code. Which also works perfectly without openmp, and with OMP_NUM_THREADS=1. If executed with more threads, after an almost complete normal execution, Valgrinds says:
==23723== Thread 20:
==23723== Jump to the invalid address stated on the next line
==23723== at 0x2A6EBBB8: ???
==23723== by 0x2A6EA515: ???
==23723== Address 0x2a6ebbb8 is not stack'd, malloc'd or (recently) free'd
==23723==
==23723==
==23723== Process terminating with default action of signal 11 (SIGSEGV)
==23723== Access not within mapped region at address 0x2A6EBBB8
==23723== at 0x2A6EBBB8: ???
==23723== by 0x2A6EA515: ???
==23723== If you believe this happened as a result of a stack
==23723== overflow in your program's main thread (unlikely but
==23723== possible), you can try to increase the size of the
==23723== main thread stack using the --main-stacksize= flag.
==23723== The main thread stack size used in this run was 1048576.
==23723==
==23723== HEAP SUMMARY:
==23723== in use at exit: 632,995,339 bytes in 101 blocks
==23723== total heap usage: 10,071 allocs, 9,970 frees, 1,257,933,743 bytes allocated
==23723==
==23723== Thread 1:
==23723== 6,992 bytes in 23 blocks are possibly lost in loss record 47 of 74
==23723== at 0x4A04A28: calloc (vg_replace_malloc.c:467)
==23723== by 0x35A0E11812: _dl_allocate_tls (dl-tls.c:300)
==23723== by 0x35A1E07068: pthread_create##GLIBC_2.2.5 (allocatestack.c:571)
==23723== by 0x2A6EA981: ???
==23723== by 0x2A4C666E: ???
==23723== by 0x4C8DB7: solvermodule (in /home/tom/bin/solver)
==23723== by 0x4C6794: MAIN__ (qdiff4v.f90:749)
==23723== by 0x4C8DF9: main (in /home/tom/bin/solver)
==23723==
==23723== 30,276 bytes in 1 blocks are definitely lost in loss record 50 of 74
==23723== at 0x4A0674C: operator new[](unsigned long) (vg_replace_malloc.c:305)
==23723== by 0x2A4C6394: ???
==23723== by 0x4C8DB7: solvermodule (in /home/tom/bin/solver)
==23723== by 0x4C6794: MAIN__ (qdiff4v.f90:749)
==23723== by 0x4C8DF9: main (in /home/tom/bin/solver)
==23723==
==23723== 30,276 bytes in 1 blocks are definitely lost in loss record 51 of 74
==23723== at 0x4A0674C: operator new[](unsigned long) (vg_replace_malloc.c:305)
==23723== by 0x2A4C63BF: ???
==23723== by 0x4C8DB7: solvermodule (in /home/tom/bin/solver)
==23723== by 0x4C6794: MAIN__ (qdiff4v.f90:749)
==23723== by 0x4C8DF9: main (in /home/tom/bin/solver)
==23723==
==23723== 30,276 bytes in 1 blocks are definitely lost in loss record 52 of 74
==23723== at 0x4A0674C: operator new[](unsigned long) (vg_replace_malloc.c:305)
==23723== by 0x2A4C63EA: ???
==23723== by 0x4C8DB7: solvermodule (in /home/tom/bin/solver)
==23723== by 0x4C6794: MAIN__ (qdiff4v.f90:749)
==23723== by 0x4C8DF9: main (in /home/tom/bin/solver)
==23723==
==23723== 30,276 bytes in 1 blocks are definitely lost in loss record 53 of 74
==23723== at 0x4A0674C: operator new[](unsigned long) (vg_replace_malloc.c:305)
==23723== by 0x2A4C6415: ???
==23723== by 0x4C8DB7: solvermodule (in /home/tom/bin/solver)
==23723== by 0x4C6794: MAIN__ (qdiff4v.f90:749)
==23723== by 0x4C8DF9: main (in /home/tom/bin/solver)
==23723==
==23723== 39,232 bytes in 1 blocks are definitely lost in loss record 57 of 74
==23723== at 0x4A0674C: operator new[](unsigned long) (vg_replace_malloc.c:305)
==23723== by 0x2A4C6369: ???
==23723== by 0x4C8DB7: solvermodule (in /home/tom/bin/solver)
==23723== by 0x4C6794: MAIN__ (qdiff4v.f90:749)
==23723== by 0x4C8DF9: main (in /home/tom/bin/solver)
==23723==
==23723== LEAK SUMMARY:
==23723== definitely lost: 160,336 bytes in 5 blocks
==23723== indirectly lost: 0 bytes in 0 blocks
==23723== possibly lost: 6,992 bytes in 23 blocks
==23723== still reachable: 632,828,011 bytes in 73 blocks
==23723== suppressed: 0 bytes in 0 blocks
==23723== Reachable blocks (those to which a pointer was found) are not shown.
==23723== To see them, rerun with: --leak-check=full --show-reachable=yes
==23723==
==23723== For counts of detected and suppressed errors, rerun with: -v
==23723== ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 6 from 6)
gdb says:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff5a04700 (LWP 23837)]
0x00007ffff7024bc2 in ?? ()
Missing separate debuginfos, use: debuginfo-install libgcc-4.4.6-4.el6.x86_64 libgfortran-4.4.6-4.el6.x86_64 libgomp-4.4.6-4.el6.x86_64 libstdc++-4.4.6-4.el6.x86_64
which clearly doesn't help. I've been playing with GOMP_STACKSIZE and the number of threads,
thinking that I may have a stack size problem, but to no avail.
I'm missing something. Maybe something stupid. And cannot find it.
This is a bug in GCC. I found a bug reported on GCC about problems related to the use of openmp and the iso_c_binding module. After that I Compiled and executed the code using the intel compiler with no problem whatsoever.
My code is quite long, and have no idea how to isolate the problematic part to reproduce the bug and make a report. Will do my best to do that.
I'm using gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4), CentOS release 6.3 (Final).
I'll mark this as the answer, and if I find anything more usefull later I'll post it here because it may be usefull to others.