Re: [Valgrind-users] Is VG_REGPARM inlining?
Am 01.10.2012 23:47, schrieb Wonjoon Song: In the example lackey, there is static VG_REGPARM(2) void trace_load(Addr addr, SizeT size); I saw a pdf http://valgrind.org/docs/iiswc2006.pdf that VG_REGPARM passes arguments using registers instead of stack. Is this inlining? No. VG_REGPARM(x) changes the used calling convention for a given function such that more registers are used for parameters. It is a convention in Valgrind that functions called from generated code have to obey a calling convention using VG_REGPARM(x) if x parameters are to be passed. This will speed up such calls on platforms where the default calling convention uses the stack to pass parameters (most important x86/32bit). As trace_load() is to be called from generated code, it has to use this calling convention. If it is not, what can i do to inline functions? because it says I can improve speed using inlining. Inlining means embedding of instructions of a function into a caller site. As the caller here always is generated code, inlining here means to embed code generated at static time into the dynamically generated code at runtime. This could be done, but Valgrind currently does not support it (Intels PIN tool does). Instead, if you care about such optimizations, the current solution is to directly generate VEX code in your instrumentation function, instead of calling a precompiled function. Josef Thank you, Wonjoon -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net 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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] closing bracket of destructor
On Tuesday 02 October 2012 14:55:57 jody wrote: Th puzzling thing is that WorldTile.cpp:267 and TDWorker.cpp:130 refer to the closing brackets of the respective destructors. What does that mean? This is where the local variables (the ones created on the stack) get deleted, obviously. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 -- 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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] closing bracket of destructor
On 02/10/12 13:55, jody wrote:
I also don't understand why the Cell is deleted twice, because
destroyGrid() does this in a loop (see below),
and all other destructors are called only once.
-
void CellGrid::destroyGrid() {
if (m_apCells != NULL) {
for (coord j = 0; j m_iNumCells; j++) {
if (m_apCells[j] != NULL) {
delete m_apCells[j];
}
}
delete[] m_apCells;
}
// other stuff unrelated to m_apCells
}
Although you check for m_apCells being null before doing the cleanup
here you don't actually set it to null after the delete, so if this
routine is called a second time it will try and cleanup an array that
has already been freed.
-
Since this error does not appear for smaller array sizes, i suspect there
must be some overwriting, but valgrind does not report this...
Are smaller arrays perhaps handled by a fixed size array of cells that
is part of the objects, with dynamic allocation of an auxiliary cell
array only being used when the cell count gets too large?
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
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
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] closing bracket of destructor
@Tom: Thank you for pointing the NULL thing out. When i debugged the code and sporadically checked which index of the array was currently being deleted, i noticed that a while after 50'000 the index was 9'000. The type 'coord' of the index j was a unsigned short int. So when the number of Cells was greater than 65535 the counter would wrap over to 0 and start deleting the cells with low indices for the second time. So now only my curiosity question about the closing brackets remain :) Jody On Tue, Oct 2, 2012 at 3:35 PM, jody jody@gmail.com wrote: Thanks for the explanation. However, i wrote a small test program with some dummy classes A, B, C all of which have local variables in their destructors. An in the constructor of C a B is created, and in the constructor of B an A is created. The destructor of C deletes the B instance, which in tur deletes its a instance. A creates an error by deleting an array twice. Here valgrind correctly shows the error source but it never mentions a closing bracket. So the question now is: under which circumstances are the closing brackets of destructors listed in a call stack? And why is the closing bracket of the destructor listed as the caller of the destructor itself? Jody On Tue, Oct 2, 2012 at 5:02 PM, David Faure fa...@kde.org wrote: On Tuesday 02 October 2012 14:55:57 jody wrote: Th puzzling thing is that WorldTile.cpp:267 and TDWorker.cpp:130 refer to the closing brackets of the respective destructors. What does that mean? This is where the local variables (the ones created on the stack) get deleted, obviously. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 -- 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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] closing bracket of destructor
On 10/2/2012 7:33 AM, Patrick J. LoPresti wrote:
On Tue, Oct 2, 2012 at 5:55 AM, jody jody@gmail.com wrote:
-
void CellGrid::destroyGrid() {
if (m_apCells != NULL) {
for (coord j = 0; j m_iNumCells; j++) {
if (m_apCells[j] != NULL) {
delete m_apCells[j];
}
}
delete[] m_apCells;
}
// other stuff unrelated to m_apCells
}
This is not related to your problem, but... In C++ -- all versions
ever, standard or otherwise -- calling delete on a NULL pointer is
guaranteed to be a no-op. So there is never a need to check for NULL
before calling delete. Doing so makes your code run slower, makes
it harder to read, and makes the reader wonder whether the author
simply does not know C++ or is trying to work around some obscure bug
in some compiler.
- Pat
It wasn't so obscure 20 years ago - programs compiled with Zortech C++
would crash if you called a virtual destructor for a NULL pointer. That
wasn't fixed for a couple of versions. Fortunately, all C++ compilers
of which I am aware today handle this properly and the NULL check is
truly redundant. But I still find can't delete 0 in Zortech comments
in some of my oldest C++ code.
And now back to your regularly scheduled programming...
--
David Chapman dcchap...@acm.org
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com
--
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
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] Large application SIGSEGV when run in valgrind
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: CStdStrwchar_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: CStdStrwchar_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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Large application SIGSEGV when run in valgrind
On Tuesday 02 October 2012 12:27:12 Pierre-Luc Provencal wrote: ==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) Greetings from Provence :-) What does the code at these two lines, say? Unless valgrind is wrong, something funky is being done by that code, so it might help to see what it's doing. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 -- 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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] closing bracket of destructor
On Tue, Oct 2, 2012 at 9:16 AM, John Reiser jrei...@bitwagon.com wrote: Not necessarily. Yes, necessarily. In *your* favorite modern CPU, a transfer of control to a non-local destination can cost 15 times as much as a local test-and- skip-over, depending on branch prediction and Icache misses. True but irrelevant. As I said, delete of NULL is guaranteed by the language to be a no-op; i.e., when the pointer is null, the destructor is not invoked. The compiler emits an inline null check even with optimization disabled. Particularly if 'delete' has not been called recently, then code which uses a local guard might be faster. No, the code with your own guard is never faster under any circumstances. At best it can be the same speed if your compiler is smart enough to recognize the test as redundant. It is also true that prevalent compilers don't make the obvious optimization of removing the test. Also wrong. The current GCC (4.7.1) omits the redundant null check when optimization is enabled. An unconditional breakpoint is much faster (no dynamic cost unless triggered) than a conditional one. Yes, let's all make our code longer, harder to read, and slower, just in case somebody inserts a breakpoint there and wants it to run a few nanoseconds faster under the debugger. I always heard engineering is about trade-offs; this must be one of those times. John, I know how much you love to argue with me, but you would save others some time if you would check your facts first. - Pat -- 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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Large application SIGSEGV when run in valgrind
Well, This is just initialization for a static member from the class CBase64: ==11125==by 0x8188CED: __static_initialization_and_destruction_0(int, int) (Base64.cpp:29): 27 28 CXString CBase64::m_sBase64Alphabet = 29 ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/; 30 The other line is just the end of the file. ==11125==by 0x8188D2F: global constructors keyed to Base64.cpp (Base64.cpp:121) My guess is that the constructor code resides at the end of the code for the current file, but this is just my guess. ;-) Pierre From: fa...@kde.org To: valgrind-users@lists.sourceforge.net CC: pierr...@hotmail.com Subject: Re: [Valgrind-users] Large application SIGSEGV when run in valgrind Date: Tue, 2 Oct 2012 18:38:07 + On Tuesday 02 October 2012 12:27:12 Pierre-Luc Provencal wrote: ==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) Greetings from Provence :-) What does the code at these two lines, say? Unless valgrind is wrong, something funky is being done by that code, so it might help to see what it's doing. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 -- 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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Large application SIGSEGV when run in valgrind
On 10/02/2012 09:27 AM, Pierre-Luc Provencal wrote: 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. What is large is not necessarily the 19MB program, but the use of almost 4GiB of address space. 0xFECB7114 is within 20MB or so of the architectural limit on a 32-bit address. In addition to the architectural limit, the software which provides a 32-bit environment on a 64-bit machine imposes an even lower limit on a 32-bit address. There is a large gain in speed if some high 32-bit addresses can be reserved for use by the operating system and libc, instead of making the entire 4GiB range available to the 32-bit client (memcheck, including the program being checked.) The reserved amount is at least 256KiB, but might be enough to cover 20MiB, which would tend to explain some of the problems you see. In any case, please run cat /proc/PID/maps (where PID is the numerical process ID) and show us what the mappings look like for addresses 0xFE00 and above, when the program hits the memcheck error (or shortly before.) -- -- 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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Large application SIGSEGV when run in valgrind
On Tue, 2012-10-02 at 12:48 -0700, John Reiser wrote: In any case, please run cat /proc/PID/maps (where PID is the numerical process ID) and show us what the mappings look like for addresses 0xFE00 and above, when the program hits the memcheck error (or shortly before.) The easiest to obtain this info when the segv is triggered is to start with --vgdb-error=1, then attach with gdb/vgdb when the error is reported. In gdb, you can then use: monitor v.info memory aspacemgr # this will show the set of mappings as seen by Valgrind shell cat /proc/pidmaps # this will show the mappings as seen by the kernel Philippe -- 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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
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: CStdStrwchar_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 0400-0401e000 r-xp 08:01 347089 /lib/ld-2.12.so ## shared libraries [snip] 08048000-0828d000 r-xp 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 00:00 0 082aa000-082ab000 rwxp 00:00 0 3800-382ab000 r-xp 1000 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 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 CStdStrwchar_t. 81d6-82785000 rwxp 00:00 0 [snip] 866fa000-867fa000 rwxp 00:00 0 867fa000-867fc000 ---p 00:00 0 # is this the hole between two thread stacks? feabb000-feabe000 rwxp 00:00 0 ffaab000-ffac rw-p 00:00 0 [stack] ## So the reserved area is about (0x1 - 0xffac) == 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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Large application SIGSEGV when run in valgrind
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: jrei...@bitwagon.com CC: valgrind-users@lists.sourceforge.net 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: CStdStrwchar_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 0400-0401e000 r-xp 08:01 347089 /lib/ld-2.12.so ## shared libraries [snip] 08048000-0828d000 r-xp 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 00:00 0 082aa000-082ab000 rwxp 00:00 0 3800-382ab000 r-xp 1000 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 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 CStdStrwchar_t. 81d6-82785000 rwxp 00:00 0 [snip] 866fa000-867fa000 rwxp 00:00 0 867fa000-867fc000 ---p 00:00 0 # is this the hole between two thread stacks? feabb000-feabe000 rwxp 00:00 0 ffaab000-ffac rw-p 00:00 0 [stack] ## So the reserved area is about (0x1 - 0xffac) == 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 Valgrind-users@lists.sourceforge.net 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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
