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 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?
I am trying to install torque 6.0.2 on Debian 8.5 on a Intel Xeon E5-2620v4. However, when i try start pbs_server i returned a segment fault, with gdb:
#1 0x0000000000440ab6 in container::item_container<pbsnode*>::unlock (this=0xb5d900 <allnodes>) at ../../src/include/container.hpp:537
#2 0x00000000004b787f in mom_hierarchy_handler::nextNode (this=0x4e610c0 <hierarchy_handler>, iter=0x7fffffff98b8) at mom_hierarchy_handler.cpp:122
#3 0x00000000004b7a7d in mom_hierarchy_handler::make_default_hierarchy (this=0x4e610c0 <hierarchy_handler>) at mom_hierarchy_handler.cpp:149
#4 0x00000000004b898d in mom_hierarchy_handler::loadHierarchy (this=0x4e610c0 <hierarchy_handler>) at mom_hierarchy_handler.cpp:433
#5 0x00000000004b8ae8 in mom_hierarchy_handler::initialLoadHierarchy (this=0x4e610c0 <hierarchy_handler>) at mom_hierarchy_handler.cpp:472
#6 0x000000000045262a in pbsd_init (type=1) at pbsd_init.c:2299
#7 0x00000000004591ff in main (argc=2, argv=0x7fffffffdec8) at pbsd_main.c:1883
dmesg:
traps: pbs_server[22249] general protection ip:7f9c08a7a2c8 sp:7ffe520b5238 error:0 in libpthread-2.19.so[7f9c08a69000+18000]
valgrind:
==22381== Memcheck, a memory error detector
==22381== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==22381== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==22381== Command: pbs_server
==22381==
==22381==
==22381== HEAP SUMMARY:
==22381== in use at exit: 18,051 bytes in 53 blocks
==22381== total heap usage: 169 allocs, 116 frees, 42,410 bytes allocated
==22381==
==22382==
==22382== HEAP SUMMARY:
==22382== in use at exit: 19,755 bytes in 56 blocks
==22382== total heap usage: 172 allocs, 116 frees, 44,114 bytes allocated
==22382==
==22381== LEAK SUMMARY:
==22381== definitely lost: 0 bytes in 0 blocks
==22381== indirectly lost: 0 bytes in 0 blocks
==22381== possibly lost: 0 bytes in 0 blocks
==22381== still reachable: 18,051 bytes in 53 blocks
==22381== suppressed: 0 bytes in 0 blocks
==22381== Rerun with --leak-check=full to see details of leaked memory
==22381==
==22381== For counts of detected and suppressed errors, rerun with: -v
==22381== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==22383==
==22383== Process terminating with default action of signal 11 (SIGSEGV)
==22383== General Protection Fault
==22383== at 0x72192CB: __lll_unlock_elision (elision-unlock.c:33)
==22383== by 0x4E7E1A: unlock_node(pbsnode*, char const*, char const*, int) (u_lock_ctl.c:268)
==22383== by 0x4B7A66: mom_hierarchy_handler::make_default_hierarchy() (mom_hierarchy_handler.cpp:164)
==22383== by 0x4B898C: mom_hierarchy_handler::loadHierarchy() (mom_hierarchy_handler.cpp:433)
==22383== by 0x4B8AE7: mom_hierarchy_handler::initialLoadHierarchy() (mom_hierarchy_handler.cpp:472)
==22383== by 0x452629: pbsd_init(int) (pbsd_init.c:2299)
==22383== by 0x4591FE: main (pbsd_main.c:1883)
==22382== LEAK SUMMARY:
==22382== definitely lost: 0 bytes in 0 blocks
==22382== indirectly lost: 0 bytes in 0 blocks
==22382== possibly lost: 0 bytes in 0 blocks
==22382== still reachable: 19,755 bytes in 56 blocks
==22382== suppressed: 0 bytes in 0 blocks
==22382== Rerun with --leak-check=full to see details of leaked memory
==22382==
==22382== For counts of detected and suppressed errors, rerun with: -v
==22382== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==22383==
==22383== HEAP SUMMARY:
==22383== in use at exit: 325,348 bytes in 186 blocks
==22383== total heap usage: 297 allocs, 111 frees, 442,971 bytes allocated
==22383==
==22383== LEAK SUMMARY:
==22383== definitely lost: 134 bytes in 6 blocks
==22383== indirectly lost: 28 bytes in 3 blocks
==22383== possibly lost: 524 bytes in 17 blocks
==22383== still reachable: 324,662 bytes in 160 blocks
==22383== suppressed: 0 bytes in 0 blocks
==22383== Rerun with --leak-check=full to see details of leaked memory
==22383==
==22383== For counts of detected and suppressed errors, rerun with: -v
==22383== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
~
No other software have this behavior, i tested the machine by 2 days with full load without problens. Already try to update the processors microcode. Please, anybody have this behavior with torque 6.0.2 or some othe scenarios ?
Best regards.
This is no microcode fault. It is an outright lock balance issue in whatever software you're running (and not in glibc/libpthreads).
Don't try to unlock an already unlocked lock. That's forbidden behavior, and the reason for the trap.
For performance reasons, glibc doesn't bother to test for it and segfault, so a lot of broken code got away with it for a long time. The hardware implementations of lock elision, OTOH, do raise traps (Intel TSX, IBM Power 8, S390/X...), so this kind of breakage is going to become apparent everywhere, very fast.
Very new to c++ but got my hands on valgrind that I played with during the day. Got my code cleaned up nicely, except from a part that uses an external library (xqilla). What I can see there is both a memory leak and error. Does this mean I should look at a different library or is it common that libraries has errors and small leaks that I shouldn't care about it?
Valgrind output
==8779== Syscall param sendmsg(mmsg[0].msg_hdr) points to uninitialised byte(s)
==8779== at 0x6065829: sendmmsg (sendmmsg.c:32)
==8779== by 0x767C8FD: __libc_res_nsend (res_send.c:1140)
==8779== by 0x7679D48: __libc_res_nquery (res_query.c:226)
==8779== by 0x767A6F8: __libc_res_nsearch (res_query.c:582)
==8779== by 0x746CB57: _nss_dns_gethostbyname4_r (dns-host.c:314)
==8779== by 0x6035ADF: gaih_inet (getaddrinfo.c:849)
==8779== by 0x6039913: getaddrinfo (getaddrinfo.c:2473)
==8779== by 0x50B3F06: xercesc_3_1::UnixHTTPURLInputStream::UnixHTTPURLInputStream(xercesc_3_1::XMLURL const&, xercesc_3_1::XMLNetHTTPInfo const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x50B3A44: xercesc_3_1::SocketNetAccessor::makeNew(xercesc_3_1::XMLURL const&, xercesc_3_1::XMLNetHTTPInfo const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x4F8813A: xercesc_3_1::XMLURL::makeNewStream() const (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x4FEC737: xercesc_3_1::ReaderMgr::createReader(xercesc_3_1::InputSource const&, bool, xercesc_3_1::XMLReader::RefFrom, xercesc_3_1::XMLReader::Types, xercesc_3_1::XMLReader::Sources, bool, unsigned long) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x4FE6758: xercesc_3_1::IGXMLScanner::scanReset(xercesc_3_1::InputSource const&) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== Address 0x7feffdad0 is on thread 1's stack
==8779==
Hello
Good
Bye
==8779==
==8779== HEAP SUMMARY:
==8779== in use at exit: 11 bytes in 1 blocks
==8779== total heap usage: 8,144 allocs, 8,143 frees, 1,957,496 bytes allocated
==8779==
==8779== 11 bytes in 1 blocks are definitely lost in loss record 1 of 1
==8779== at 0x4C2A879: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8779== by 0x4FEC508: xercesc_3_1::MemoryManagerImpl::allocate(unsigned long) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x50B87D5: xercesc_3_1::IconvGNULCPTranscoder::transcode(unsigned short const*, xercesc_3_1::MemoryManager*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x50B3C6D: xercesc_3_1::UnixHTTPURLInputStream::UnixHTTPURLInputStream(xercesc_3_1::XMLURL const&, xercesc_3_1::XMLNetHTTPInfo const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x50B3A44: xercesc_3_1::SocketNetAccessor::makeNew(xercesc_3_1::XMLURL const&, xercesc_3_1::XMLNetHTTPInfo const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x4F8813A: xercesc_3_1::XMLURL::makeNewStream() const (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x4FEC737: xercesc_3_1::ReaderMgr::createReader(xercesc_3_1::InputSource const&, bool, xercesc_3_1::XMLReader::RefFrom, xercesc_3_1::XMLReader::Types, xercesc_3_1::XMLReader::Sources, bool, unsigned long) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x4FE6758: xercesc_3_1::IGXMLScanner::scanReset(xercesc_3_1::InputSource const&) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x4FE0D03: xercesc_3_1::IGXMLScanner::scanDocument(xercesc_3_1::InputSource const&) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x50053B8: xercesc_3_1::XMLScanner::scanDocument(unsigned short const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x5008931: xercesc_3_1::XMLScanner::scanDocument(char const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x5027474: xercesc_3_1::AbstractDOMParser::parse(char const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779==
==8779== LEAK SUMMARY:
==8779== definitely lost: 11 bytes in 1 blocks
==8779== indirectly lost: 0 bytes in 0 blocks
==8779== possibly lost: 0 bytes in 0 blocks
==8779== still reachable: 0 bytes in 0 blocks
==8779== suppressed: 0 bytes in 0 blocks
==8779==
==8779== For counts of detected and suppressed errors, rerun with: -v
==8779== Use --track-origins=yes to see where uninitialised values come from
==8779== ERROR SUMMARY: 5 errors from 2 contexts (suppressed: 2 from 2)
If the library is indeed leaking memory, it would be wise to resolve it as the leak could eventually impact the application. Typical symptoms of a memory leak include a hung process, or a process that terminates abruptly (such as when the Linux out-of-memory killer goes to work).
Looking for another library may be viable. If the library maintainers can be reached, it would be good to bring it to their attention. And, if it is open source, it would be even more awesome to track it down and submit a fix.
One thing to consider here though. Valgrind is going to flag any memory that is not eventually released as a leak. The library may be making one-time allocations, such as creating singletons. If that's the case, then it is really a non-problem.
So, things to try:
Track down what interactions with the library create the leaks
Confirm that those interactions actually leak - meaning that they make more than one allocation over time
Check the library for operations that may clean up the memory
Verify the use of the library (for example, make sure a cleanup method/function that should be called is being called)
Contact the maintainers
Track it down and fix it (if it's opensource)
The errors referring to the pointers to uninitialized bytes does not necessarily mean anything is wrong, just that the library has allocated pointers and not set the allocated memory to any value. If the program runs into segmentation faults, those errors could be helpful to track them down. Otherwise, it could be totally normal. For example, the library may be pre-allocating buffers for later use.
Again, I would consider mentioning them to maintainers, but those errors by themselves are not too worrisome.
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.