|
From: Kalaivani R <kal...@gm...> - 2013-01-09 15:14:41
|
Hi, I installed valgrind 3.8.1 and when I tried to run with a C++ executable it always terminates with SIGSEGV for a C++ static variable initialization. Is there any fix available for this issue in valgrind? We could not proceed further. We tried to check for patches but we could not succeed. We faced the same problem with the earlier version of valgrind as well (3.1.1) *glibc version:* ldd (GNU libc) 2.3.4 *gcc version: *gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-11) Thanks, Kalai ==19332== Process terminating with default action of signal 11 (SIGSEGV) ==19332== Access not within mapped region at address 0x0 ==19332== at 0x4009A34: memset (mc_replace_strmem.c:1007) ==19332== by 0x40C7D0A: Heap::Heap() (Heap.cpp:61) ==19332== by 0x40CB41E: operator new(unsigned int) (NewDelete.cpp:23) ==19332== by 0x4644055: __static_initialization_and_destruction_0(int, int) (LteEgtpCli.cpp:30) ==19332== by 0x46440B2: global constructors keyed to SendEgtpuMsg::egtpRxEgtpRB (LteEgtpCli.cpp:994) ==19332== by 0x464C9C0: ??? (in /root/enb/lib/liblteegtp.so) ==19332== by 0x4641C3C: ??? (in /root/enb/lib/liblteegtp.so) ==19332== by 0x25C897: _dl_init (in /lib/ld-2.3.4.so) ==19332== by 0x2507FE: ??? (in /lib/ld-2.3.4.so) ==19332== If you believe this happened as a result of a stack ==19332== overflow in your program's main thread (unlikely but ==19332== possible), you can try to increase the size of the ==19332== main thread stack using the --main-stacksize= flag. ==19332== The main thread stack size used in this run was 10485760. ==19332== ==19332== HEAP SUMMARY: ==19332== in use at exit: 0 bytes in 0 blocks ==19332== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==19332== ==19332== All heap blocks were freed -- no leaks are possible ==19332== ==19332== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 86 from 8) ==19332== ==19332== 1 errors in context 1 of 1: ==19332== Invalid write of size 4 ==19332== at 0x4009A34: memset (mc_replace_strmem.c:1007) ==19332== by 0x40C7D0A: Heap::Heap() (Heap.cpp:61) ==19332== by 0x40CB41E: operator new(unsigned int) (NewDelete.cpp:23) ==19332== by 0x4644055: __static_initialization_and_destruction_0(int, int) (LteEgtpCli.cpp:30) ==19332== by 0x46440B2: global constructors keyed to SendEgtpuMsg::egtpRxEgtpRB (LteEgtpCli.cpp:994) ==19332== by 0x464C9C0: ??? (in /root/enb/lib/liblteegtp.so) ==19332== by 0x4641C3C: ??? (in /root/enb/lib/liblteegtp.so) ==19332== by 0x25C897: _dl_init (in /lib/ld-2.3.4.so) ==19332== by 0x2507FE: ??? (in /lib/ld-2.3.4.so) ==19332== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==19332== |
|
From: Alexander P. <gl...@go...> - 2013-01-09 15:24:34
|
On Wed, Jan 9, 2013 at 7:14 PM, Kalaivani R <kal...@gm...> wrote: > Hi, > I installed valgrind 3.8.1 and when I tried to run with a C++ executable it > always terminates with SIGSEGV for a C++ static variable initialization. > Is there any fix available for this issue in valgrind? > We could not proceed further. We tried to check for patches but we could not > succeed. > We faced the same problem with the earlier version of valgrind as well > (3.1.1) > glibc version: ldd (GNU libc) 2.3.4 > gcc version: gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-11) > > Thanks, > Kalai > > ==19332== Process terminating with default action of signal 11 (SIGSEGV) > ==19332== Access not within mapped region at address 0x0 > ==19332== at 0x4009A34: memset (mc_replace_strmem.c:1007) > ==19332== by 0x40C7D0A: Heap::Heap() (Heap.cpp:61) > ==19332== by 0x40CB41E: operator new(unsigned int) (NewDelete.cpp:23) > ==19332== by 0x4644055: __static_initialization_and_destruction_0(int, > int) (LteEgtpCli.cpp:30) > ==19332== by 0x46440B2: global constructors keyed to > SendEgtpuMsg::egtpRxEgtpRB (LteEgtpCli.cpp:994) > ==19332== by 0x464C9C0: ??? (in /root/enb/lib/liblteegtp.so) > ==19332== by 0x4641C3C: ??? (in /root/enb/lib/liblteegtp.so) > ==19332== by 0x25C897: _dl_init (in /lib/ld-2.3.4.so) > ==19332== by 0x2507FE: ??? (in /lib/ld-2.3.4.so) > ==19332== If you believe this happened as a result of a stack > ==19332== overflow in your program's main thread (unlikely but > ==19332== possible), you can try to increase the size of the > ==19332== main thread stack using the --main-stacksize= flag. > ==19332== The main thread stack size used in this run was 10485760. > ==19332== > ==19332== HEAP SUMMARY: > ==19332== in use at exit: 0 bytes in 0 blocks > ==19332== total heap usage: 0 allocs, 0 frees, 0 bytes allocated > ==19332== > ==19332== All heap blocks were freed -- no leaks are possible > ==19332== > ==19332== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 86 from 8) > ==19332== > ==19332== 1 errors in context 1 of 1: > ==19332== Invalid write of size 4 > ==19332== at 0x4009A34: memset (mc_replace_strmem.c:1007) > ==19332== by 0x40C7D0A: Heap::Heap() (Heap.cpp:61) > ==19332== by 0x40CB41E: operator new(unsigned int) (NewDelete.cpp:23) > ==19332== by 0x4644055: __static_initialization_and_destruction_0(int, > int) (LteEgtpCli.cpp:30) > ==19332== by 0x46440B2: global constructors keyed to > SendEgtpuMsg::egtpRxEgtpRB (LteEgtpCli.cpp:994) > ==19332== by 0x464C9C0: ??? (in /root/enb/lib/liblteegtp.so) > ==19332== by 0x4641C3C: ??? (in /root/enb/lib/liblteegtp.so) > ==19332== by 0x25C897: _dl_init (in /lib/ld-2.3.4.so) > ==19332== by 0x2507FE: ??? (in /lib/ld-2.3.4.so) > ==19332== Address 0x0 is not stack'd, malloc'd or (recently) free'd > ==19332== Apparently your program is trying to write to a NULL pointer. There's nothing Valgrind should do about this. Check your code at Heap.cpp:61 and make sure you're passing the correct values to memset(). |
|
From: Kalaivani R <kal...@gm...> - 2013-01-09 15:36:34
|
We have checked the code base.
It starts from a class's static variable definition in one of our internal
CPP files.
>From there it says global contructors keyed to and then inturn to memset.
We are always getting valgrind core immediately when we start the valgrind
for our image.
Below is the backtrace of the valgrind core. The static variable
initialization is the one that triggers the segmentation fault.
Is it possible to run valgrind completely for my binary without terminating
in between due to any of these signals like SIGSEGV.
Do we have any such options to configure valgrind or is there any patch or
workaround for this issue?
Thanks,
Kalai
#0 0x04009a34 in _vgr20210ZU_libcZdsoZa_memset (s=0x0, c=0, n=22150000) at
mc_replace_strmem.c:1007
1007 MEMSET(VG_Z_LIBC_SONAME, memset)
(gdb) bt
#0 0x04009a34 in _vgr20210ZU_libcZdsoZa_memset (s=0x0, c=0, n=22150000) at
mc_replace_strmem.c:1007
#1 0x040c7d0b in Heap (this=0x8060e00) at
/vobs/eps_fw/New/./src/Heap.cpp:61
#2 0x040cb41f in operator new (size=24) at
/vobs/eps_fw/New/./src/NewDelete.cpp:23
#3 0x040ed2ec in __static_initialization_and_destruction_0
(__initialize_p=1, __priority=65535)
at /vobs/eps_fw/Telnet/./src/TelnetClient.cpp:31
#4 0x040ed3a3 in global constructors keyed to
_ZN12TelnetClient27numberOpenClientConnectionsE ()
at /vobs/eps_fw/Telnet/./src/TelnetClient.cpp:275
#5 0x040f0885 in __do_global_ctors_aux () from /root/enb/lib/libTelnet.so
#6 0x040ebbe5 in _init () from /root/enb/lib/libTelnet.so
#7 0x0044d898 in _dl_init_internal () from /lib/ld-linux.so.2
#8 0x004417ff in _dl_start_user () from /lib/ld-linux.so.2
Current language: auto; currently c
===================================================================================================
==19332== Process terminating with default action of signal 11 (SIGSEGV)
==19332== Access not within mapped region at address 0x0
==19332== at 0x4009A34: memset (mc_replace_strmem.c:1007)
==19332== by 0x40C7D0A: Heap::Heap() (Heap.cpp:61)
==19332== by 0x40CB41E: operator new(unsigned int) (NewDelete.cpp:23)
==19332== by 0x4644055: __static_initialization_and_destruction_0(int,
int) (LteEgtpCli.cpp:30)
==19332== by 0x46440B2: global constructors keyed to
SendEgtpuMsg::egtpRxEgtpRB (LteEgtpCli.cpp:994)
==19332== by 0x464C9C0: ??? (in /root/enb/lib/liblteegtp.so)
==19332== by 0x4641C3C: ??? (in /root/enb/lib/liblteegtp.so)
==19332== by 0x25C897: _dl_init (in /lib/ld-2.3.4.so)
==19332== by 0x2507FE: ??? (in /lib/ld-2.3.4.so)
==19332== If you believe this happened as a result of a stack
==19332== overflow in your program's main thread (unlikely but
==19332== possible), you can try to increase the size of the
==19332== main thread stack using the --main-stacksize= flag.
==19332== The main thread stack size used in this run was 10485760.
On Wed, Jan 9, 2013 at 8:54 PM, Alexander Potapenko <gl...@go...>wrote:
> Valgrind
--
Cheers,
Kalai
|
|
From: Alexander P. <gl...@go...> - 2013-01-09 16:03:11
|
> #0 0x04009a34 in _vgr20210ZU_libcZdsoZa_memset (s=0x0, c=0, n=22150000) at > mc_replace_strmem.c:1007 This line clearly denotes that for some reason memset(0, 0, 22150000) is being called. You can insert assert(first_parameter_of_memset) before that line in order to make sure it is (or is not) NULL. Most probably this is a bug in your code - in this case Valgrind can't fix it for you. Recovering from SIGSEGV is a tricky thing which is not what most people ever need. -- Alexander Potapenko Software Engineer Google Moscow |