Hello,
I am new at using valgrind. I first tried it on a relatively small program, and
everything worked ok.
When I try it with a much larger program (19MB), I get a SIGSEGV before the
main() is actually called. It looks like the program crashes while calling in
the constructor functions. This is a 32-bit program run on a CentOs 6.2 64-bit
system. The system has 8 GB memory. The address that is being used when the
crash occurs is: Access not within mapped region at address 0xFECB7114. Which
is near 4 GB, but should be ok on a 8 GB system.
Any help is appreciated.
Here is the outout from valgrind:
[root@xms plp]# valgrind --leak-check=full test1 -cv
==11125== Memcheck, a memory error detector
==11125== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==11125== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==11125== Command: test1 -cv
==11125==
==11125== Invalid write of size 4
==11125== at 0x8055129: CStdStr<wchar_t>::CStdStr(wchar_t const*)
(XString.h:1777)
==11125== by 0x8188CED: __static_initialization_and_destruction_0(int, int)
(Base64.cpp:29)
==11125== by 0x8188D2F: global constructors keyed to Base64.cpp
(Base64.cpp:121)
==11125== by 0x81B96DC: ??? (in /usr/bin/test1)
==11125== by 0x8053427: ??? (in /usr/bin/test1)
==11125== by 0x81B95F8: __libc_csu_init (in /usr/bin/test1)
==11125== by 0x483FC83: (below main) (in /lib/libc-2.12.so)
==11125== Address 0xfecb7114 is not stack'd, malloc'd or (recently) free'd
==11125==
==11125==
==11125== Process terminating with default action of signal 11 (SIGSEGV)
==11125== Access not within mapped region at address 0xFECB7114
==11125== at 0x8055129: CStdStr<wchar_t>::CStdStr(wchar_t const*)
(XString.h:1777)
==11125== by 0x8188CED: __static_initialization_and_destruction_0(int, int)
(Base64.cpp:29)
==11125== by 0x8188D2F: global constructors keyed to Base64.cpp
(Base64.cpp:121)
==11125== by 0x81B96DC: ??? (in /usr/bin/test1)
==11125== by 0x8053427: ??? (in /usr/bin/test1)
==11125== by 0x81B95F8: __libc_csu_init (in /usr/bin/test1)
==11125== by 0x483FC83: (below main) (in /lib/libc-2.12.so)
==11125== If you believe this happened as a result of a stack
==11125== overflow in your program's main thread (unlikely but
==11125== possible), you can try to increase the size of the
==11125== main thread stack using the --main-stacksize= flag.
==11125== The main thread stack size used in this run was 10485760.
==11125==
==11125== HEAP SUMMARY:
==11125== in use at exit: 172 bytes in 2 blocks
==11125== total heap usage: 4 allocs, 2 frees, 644 bytes allocated
==11125==
==11125== 160 bytes in 1 blocks are possibly lost in loss record 2 of 2
==11125== at 0x4025F0D: calloc (vg_replace_malloc.c:593)
==11125== by 0x4011D19: _dl_allocate_tls (in /lib/ld-2.12.so)
==11125== by 0x451E328: pthread_create@@GLIBC_2.1 (in
/lib/libpthread-2.12.so)
==11125== by 0x81B4174: XBeginThread(ttThreadHandle**, void* (*)(void*),
bool, void*, int, bool) (XThreads.cpp:289)
==11125== by 0x81B6972: CXMultipleTimer::Run() (XMultipleTimer.cpp:65)
==11125== by 0x81B6701: CXMultipleTimer::CXMultipleTimer()
(XMultipleTimer.cpp:31)
==11125== by 0x81B3E6A: __static_initialization_and_destruction_0(int, int)
(XSocket.cpp:25)
==11125== by 0x81B3EAC: global constructors keyed to XSocket.cpp
(XSocket.cpp:1331)
==11125== by 0x81B96DC: ??? (in /usr/bin/test1)
==11125== by 0x8053427: ??? (in /usr/bin/test1)
==11125== by 0x81B95F8: __libc_csu_init (in /usr/bin/test1)
==11125== by 0x483FC83: (below main) (in /lib/libc-2.12.so)
==11125==
==11125== LEAK SUMMARY:
==11125== definitely lost: 0 bytes in 0 blocks
==11125== indirectly lost: 0 bytes in 0 blocks
==11125== possibly lost: 160 bytes in 1 blocks
==11125== still reachable: 12 bytes in 1 blocks
==11125== suppressed: 0 bytes in 0 blocks
==11125== Reachable blocks (those to which a pointer was found) are not shown.
==11125== To see them, rerun with: --leak-check=full --show-reachable=yes
==11125==
==11125== For counts of detected and suppressed errors, rerun with: -v
==11125== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 85 from 8)
Thanks,
Pierre
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
