Access violation writing location by MKL_FreeBuffers

[xertin]

Has anyone run into a problem of access violation when calling MKL_FreeBuffers with the version 7.21 of MKL for windows?

[xertin]

Here is what I did and got the access violation (with MKL 7.2.1.0013?):

I took the file zgetrsx.f from exampleslapacksource and the data file zgetrsx.dfrom exampleslapackdata; built projects with Intel Fortran 8.1 and Compaq Visual Fotran 6.5; in zgetrfsx.fcommented out the line CALL X04DBF (which is for writing the results only) andadded CALL MKL_FreeBuffers() before the STOP statement; added ia32lib to the lib path list in the link options; added mkl_c.lib (in intel 8.1 project) or mkl_s.lib (in CVF 6.5 project). I tried to link static and dll runtime libraries. The projects built without any warning, yet alwaystriggeredan access violation. The problem seems to be in __kmp_register_library_startup.

MKL_FreeBuffers() is of interest because of the memory leak issue mentioned in the release note (mklnotes.htm). The release notes seem to have the same statements on Memory Allocation since version MKL 6.1. Yet we are not sure whether programs linked with MKL leak memory or not.

I appreciate your response to this topicif youhave successcullyusedMKL_FreeBuffers() (of MKL7.2.1.0013)in your program.

Your comments on the memory leak (as related to use of MKL) is much more deeply apprciated.

[Intel_C_Intel]

It must be from age. I thought I had responded to this posting but in looking over the various postings I see that I have not. I am not certain but I think that there would have been no buffers created for such a small problem as the example. We may not have anticipated that the buffer freeing software would be called when no buffers were created. If that is the case we need to fix that in the software. Bruce

[n_trasmussen]

Hi,

we have the exact same problem in some of our code, where we do not always use functions that use mkl, but always call a clean up function, which calls MKL_FreeBuffers, which results in the access violation described.

My question is then when will this bug be fixed?

As an additional question I could ask when will MKL 8.0 be released?

However, shouldn't this bug be fixed for MKL 7.2 too, regardless of whether or not it will be fixed in MKL 8.0?

[Intel_C_Intel]

Hi,

I use MKL 9.1.022, and called MKL_FreeBuffers()from destructor C++ class in MS VSNET 2005, whichresulted togeneral exception:

02F6C887 jle _mkl_serv_freebuffers+0C8h (2F6C924h)
02F6C88D mov dword ptr [esp],ebx
02F6C890 mov dword ptr [esp+4],esi
02F6C894 mov dword ptr [esp+8],edi
02F6C898 mov dword ptr [esp+0Ch],ebp
02F6C89C mov edx,1
02F6C8A1 mov ebx,edx
02F6C8A3 mov esi,dword ptr _afxInitAppState+2CAh (5EF3A80h)[ebx*4] 02F6C8AA mov ebp,dword ptr [esi+70h]

Where registers are:

EBPFEEEFEEE
ESI0B837730
EDX00000000
EBX00000003

In the same time this code works fine with MKL 7.2.6.

To have a control over the memory I redirected all memory functions to 
my own ones, controlling all allocated and deallocated pointers to 
avoid deallocating previously free memory (if pointer in MKL is not set
to NULL after that), which shows up that after calling the MKL_FreeBuffers()
it deallocates 5 buffers, and crashes after 6 one deallocated.

void* my_malloc(size_t size);
void* my_calloc( size_t num, size_t size );
void* my_realloc( void* memblock, size_t size );
void my_free( void* memblock);

class CAutoFreeIntelMemory
{
public:
std::set  m_pAllocated;
CAutoFreeIntelMemory()
{ 
i_malloc = my_malloc; 
i_calloc = my_calloc; 
i_realloc = my_realloc; 
i_free = my_free;
}
~CAutoFreeIntelMemory();
};
static CAutoFreeIntelMemory dummyObject;
// ----------------------------------------------------------------------------
// my_malloc
// ----------------------------------------------------------------------------
void* my_malloc(size_t size)
{
void* p = malloc( size);
dummyObject.m_pAllocated.insert( (DWORD)p);return p;
}
// ----------------------------------------------------------------------------
// my_calloc
// ----------------------------------------------------------------------------
void* my_calloc( size_t num, size_t size )
{
void* p = calloc( num, size);
dummyObject.m_pAllocated.insert( (DWORD)p);return p;
}
// ----------------------------------------------------------------------------
// my_realloc
// ----------------------------------------------------------
------------------
void* my_realloc( void* memblock, size_t size )
{
void* p = realloc( memblock, size);
dummyObject.m_pAllocated.insert( (DWORD)p);return p;
}
// ----------------------------------------------------------------------------
// my_free
// ----------------------------------------------------------------------------
void my_free( void* p)
{
std::set ::iterator setIter = dummyObject.m_pAllocated.find((DWORD)p);if ( setIter != dummyObject.m_pAllocated.end())
{// free( p);
dummyObject.m_pAllocated.erase( setIter);
}
}
CAutoFreeIntelMemory::~CAutoFreeIntelMemory()
{
MKL_FreeBuffers(); //Free memory from the intel math library.
}
It crashes independently calling of free() function in my_free(). 
Even if it's commented, as in this my piece of code
// free( p);it still internally crashes in MKL_FreeBuffers() after
the same number of calling my_free() function. 
It shows that its not GPF, called beacuse of 
second deallocation of the previously deallocated memory.

It crashedandin downloaded Beta MKL 10.0.006. The crash depends on number of MKL function calls. Depending of number of the analysis calls MKL_FreeBuffers() may be successful, or crashing. The more the analysis sweep steps, the more buffers MKL allocates, the more probability that its deallocation calls the crash.

Using my memory control functions have shown upthat the memory is not deallocated, but not accessable to free it.

Finally I found that the problem was caused bywhere the function called from, and I think it's created by multi-trading of the library. In my previous code it's called from destructor of a global variable, which's called by Windows main function, when it closed most of treads of the library, and memory access become unavailable.

Instead of calling from destructor I moved the callto the CAutoFreeIntelMemory member function in the end ofmy main Windows instance function CMyApp::ExitInstance(), where all treads and memory are available:

extern void FreeIntelMKLMemory(void);

// ----------------------------------------------------------------------------
//Ex itInstance
// ----------------------------------------------------------------------------
int CMyApp::ExitInstance()
{

.................................
..................................
FreeIntelMKLMemory();
return __super::ExitInstance();
}

where MKL memeory deallocation control variable class a nd wrapper function for it FreeIntelMKLMemory(void)are defined as:

class

CAutoFreeIntelMemory
{
public:
void FreeIntelMemory( void);
};

static

CAutoFreeIntelMemory g_cIntelMKLDummyObject;

// ----------------------------------------------------------------------------
// FreeIntelMKLMemory
// ----------------------------------------------------------------------------

void

FreeIntelMKLMemory(void)
{
g_cIntelMKLDummyObject.FreeIntelMemory();
}

void CAutoFreeIntelMemory::FreeIntelMemory(void)
{
MKL_FreeBuffers(); //Free memory from the intel math library.
}

It's fixed the issue, caused by the Intel MKLmulti-trading.

[Vladimir_Lunev]

Sergey,

To investigate the problem, I need in some details.

Please:

Did you use MKL-ia32 or MKL-em64t?
Did you use static or dynamic MKL? Which MKL libraries were linked?
Is your application dynamic or static? I.e. was MKL called from DLL or not?
Which of MKL functions did you use in your application? BLAS/FFT/...? Functions' names are welcomed.

Thanks,

-Vladimir
MKL library engineering