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
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
