C / C++ / MFC

misterMF wrote:

I have to perform a number of mathematical operations on this matrices, like C = A * B * D avoiding the creation of temporaries

void Mult3(Matrix const & A, Matrix const & B, Matrix const & D, Matrix& C)
{
   // Populate C as A * B * D
}

template< typename T >
class TTransferMatrix < std::valarray<t>> : public TTransferMatrix_base < std::valarray<t>>
{

private:
	const size_t N_ELEMENTS;    // the size of the matrices (always 2*2 = 4)
	size_t arraySize;           // the number of matrices in the array
	
       std::valarray< T > m00;	    // the matrix elements: since they are a lot
	std::valarray< T > m01;     // it can be better to use separate variables (?)
	std::valarray< T > m10;
	std::valarray< T > m11;

public:
        // public members (ctors, destructors, operators & functions)
}
</t></t>

Roger Allen wrote:

I have an application which is experiencing heap corruption being reported by NTDLL.

1. Is a release built library used with a debug built application (or the other way around) where memory allocations are done in one and deallocations in the other?
2. Is something alocated with e.g. new and then deleted with free() (or the other way around)?

Roger Stoltz wrote:

In what way is this "reported" by NTDLL?

Sometimes also see text saying that a block at

has been modified after being freed at

+offset

Roger Stoltz wrote:

Is a release built library used with a debug built application (or the other way around) where memory allocations are done in one and deallocations in the other?

The entire application is built using release versions and libraries of everything. I have used dependency walker to check all the included DLLs/dependencies and these are all release versions of the CRT etc

Roger Stoltz wrote:

Is something alocated with e.g. new and then deleted with free() (or the other way around)?

All code uses new/delete or delete [] as appropriate.

Roger Stoltz wrote:

One other thing is that the debug built version is very forgiving and I assume you've read this article[^].
It could also be an uninitialized variable that gets initialized when debug built.

I'll take a look at the article, thanks for the link

If you vote me down, my score will only get lower

Roger Allen wrote:

Sometimes also see text saying that a block at
has been modified after being freed at
+offset

Roger Stoltz wrote:

To my knowledge the only way a software keeps track of this and report it with the words you've quoted above, is if it uses the MFC framework built with new defined to DEBUG_NEW.
It could be that DEBUG_NEW is used instead of the ordinary new operator.

Roger Allen wrote:

I will check the whole app for that one.

Roger Allen wrote:

I went through PJ's article on the release build.

Roger Stoltz wrote:

Ummm, "PJ"? What article is that? Or you mean "Professor Joe"?

Roger Stoltz wrote:

Nevertheless, one thing to look for when the debug version does what it's supposed to and the release version does not, is uninitialized variables. A lot of them get initialized in the debug version behind curtains.

Roger Stoltz wrote:

It would be nice to know if, or rather when, you find something.
I'm curious and it would be a good experience for myself as well; another pitfall to avoid and possibly how to do it.

Good luck in your hunt for that illusive bug.

Roger Allen wrote:

And yes, following one of the suggestions in the article fixed our problem.

Roger Stoltz wrote:

Ummm, "PJ"? What article is that? Or you mean "Professor Joe"?

1. Are you using a multi-threaded C run-time (I'm sure you are, but am asking for completeness )
2. Are the STL objects being allocated in the same module (EXE/DLL) as they're destructed in? If not, you need to ensure you build all your different modules with a DLL version of the C run-time.

Stuart Dootson wrote:

Are you using a multi-threaded C run-time (I'm sure you are, but am asking for completeness )

Stuart Dootson wrote:

Are the STL objects being allocated in the same module (EXE/DLL) as they're destructed in? If not, you need to ensure you build all your different modules with a DLL version of the C run-time.

Joe Woodbury wrote:

My gut instinct is buffer overruns.