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 <[email protected]>wrote:
> Valgrind
--
Cheers,
Kalai
------------------------------------------------------------------------------
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
