Re: [Valgrind-users] Is VG_REGPARM inlining?

2012-10-02 Thread Josef Weidendorfer
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)

Re: [Valgrind-users] closing bracket of destructor

2012-10-02 Thread David Faure
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. --

Re: [Valgrind-users] closing bracket of destructor

2012-10-02 Thread Tom Hughes
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) {

Re: [Valgrind-users] closing bracket of destructor

2012-10-02 Thread jody
@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

Re: [Valgrind-users] closing bracket of destructor

2012-10-02 Thread David Chapman
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] !=

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

2012-10-02 Thread Pierre-Luc Provencal
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.

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

2012-10-02 Thread David Faure
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

Re: [Valgrind-users] closing bracket of destructor

2012-10-02 Thread Patrick J. LoPresti
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

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

2012-10-02 Thread Pierre-Luc Provencal
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

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

2012-10-02 Thread John Reiser
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

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

2012-10-02 Thread Philippe Waroquiers
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

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

2012-10-02 Thread John Reiser
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)

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

2012-10-02 Thread Pierre-Luc Provencal
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