On Nov 1, 2009, at 10:33 AM, Jean-Denis Muys wrote:
Followup on my memory corruption bug:
I got a few suggestions (thanks everybody):
- a memory watch point: I may be able to use that idea, but so far, I could not clearly identify a fixed location that's corrupted. - Guard Malloc: I have a machine that I started about 12 hours ago with Guard Malloc enabled. The host app hasn't finished launching yet. - Valgrind: I still have 10.5 running on a Mac mini, so I started the host app under Valgrind. It's veryyyy slow. Still running. - static analyzer: it doesn't detect anything wrong (but of course, my code is C++).
I also wanted to report that I made some significant progress on how to call malloc heap checking facility at will.
I managed to "fix" the memory corruption bug I had. Actually, I still don't understand why it used to crash and not anymore. This is a rather peculiar situation, that you might find interesting.
The following idiom corrupted memory:
long bad() { [...]
sql::ResultSet *results = preparedStmt->executeQuery();
[...]
delete results; zoneCheck();
return result; }
While this one runs fine and nice:
long good() { [...]
std::auto_ptrsql::ResultSetresults(preparedStmt->executeQuery());
[...]
zoneCheck();
return result; }
Since all std::auto_ptr does is to call delete on its internal pointer when it goes out of scope (even in case of an exception), I am still totally puzzled by this behaviour.
As an aside, the library behind all this is mySQL's C++/Connector.
I'd be interested by a possible explanation: my C++ is not sharp (no pun, really) enough to grasp all the subtleties.
Well, in the first case delete is called *before* zoneCheck, and in the second, it is called *after*. To me, that suggests that looking at the destructor for sql::ResultSet. -- Marshall