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