Re: [Boost-users] Debugging memory corruption? (C++)

Subject: Re: [Boost-users] Debugging memory corruption? (C++)
From: Marshall Clow (mclow.lists_at_[hidden])
Date: 2009-11-01 13:38:39

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_ptr<sql::ResultSet>results(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