Re: [Valgrind-users] Large application SIGSEGV when run in valgrind

[Pierre-Luc P. <pie...@ho...>]

The thing is, I could move on further by not making this one variable static, but then I got another error for another static variable somewhere else.
It really looks like static variable initialization is buggy.
Thanks,Pierre

> Date: Tue, 2 Oct 2012 15:37:44 -0700
> From: jr...@bi...
> CC: val...@li...
> Subject: Re: [Valgrind-users] Large application SIGSEGV when run in valgrind
> 
> > Using valgrind with gdb, the faulty address is now 0xFEABA104:
> > 
> > ==29254== Process terminating with default action of signal 11 (SIGSEGV)
> > ==29254==  Access not within mapped region at address 0xFEABA104
> > ==29254==    at 0x8055129: CStdStr<wchar_t>::CStdStr(wchar_t const*) (XString.h:1777)
> > ==29254==    by 0x8188CED: __static_initialization_and_destruction_0(int, int) (Base64.cpp:29)
> > ==29254==    by 0x8188D2F: global constructors keyed to Base64.cpp (Base64.cpp:121)
> > ==29254==    by 0x81B96DC: ??? (in /usr/bin/test1)
> > ==29254==    by 0x8053427: ??? (in /usr/bin/test1)
> > ==29254==    by 0x81B95F8: __libc_csu_init (in /usr/bin/test1)
> > ==29254==    by 0x483FC83: (below main) (in /lib/libc-2.12.so)
> > 
> > The address 0xFEABA104 does not seem to be mapped:
> > 
> > # cat /proc/29254/maps
> > 04000000-0401e000 r-xp 00000000 08:01 347089                             /lib/ld-2.12.so  ## shared libraries
>    [snip]
> > 08048000-0828d000 r-xp 00000000 08:01 266751                             /usr/bin/test1   ## the program being checked
> > 0828d000-08292000 rw-p 00245000 08:01 266751                             /usr/bin/test1
> > 08292000-082aa000 rw-p 00000000 00:00 0
> > 082aa000-082ab000 rwxp 00000000 00:00 0
> > 38000000-382ab000 r-xp 00001000 08:01 355740                             /usr/local/lib/valgrind/memcheck-x86-linux   ## the "main" program
> > 382ab000-382ad000 rw-p 002ab000 08:01 355740                             /usr/local/lib/valgrind/memcheck-x86-linux
> > 382ad000-38d43000 rw-p 00000000 00:00 0
> 
>   ### This gap from 0x38...... to 0x81...... is interesting.
>   ### A bad access at 0xFEABA104 is beginning to look like
>   ### bad code (sign error, etc.) in static inits or CStdStr<wchar_t>.
> 
> > 81d60000-82785000 rwxp 00000000 00:00 0
>    [snip]
> > 866fa000-867fa000 rwxp 00000000 00:00 0
> > 867fa000-867fc000 ---p 00000000 00:00 0   # is this the "hole" between two thread stacks?
> > feabb000-feabe000 rwxp 00000000 00:00 0
> > ffaab000-ffac0000 rw-p 00000000 00:00 0                                  [stack]
> 
>    ## So the reserved area is about (0x100000000 - 0xffac0000) ==> 5.5MB
>    ## which looks like 4MiB plus some deliberate randomization
>    ## as a defense against malware.
> 
> -- 
> 
> 
> ------------------------------------------------------------------------------
> 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
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users