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: [email protected]
> CC: [email protected]
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
                                          
------------------------------------------------------------------------------
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

Reply via email to