Hello,

I have dynamically allocated memory that I would like to share across threads. More specifically, I have an ACE thread pool, which I use to process requests on dynamically allocated ACE_Method_Request objects. These objects are created once at startup, and then processed throughout the system's running state (i.e. the same object is dispatched to different threads on a regular basis during system execution).

I am getting the following error:

Unhandled exception at 0xff5d7230 in Test.exe: 0xC0000005: Access violation reading location 0xff5d7230.

Btw, the dispatched objects form a hierarchy of classes. The crash seems not to occur when the code that processes the thread's request is in the parent abstract class and does not attempt to access any members from the corresponding child class. Virtual functions do not work, and I tried to use functors/function pointers to static functions defined in base classes and that does not work either.

Any thoughts?

Thanks!
Greg

Actually, to clarify, the crash seems to occur when an attempt to access the object's pointer (not its member data) occurs. Of course, accessing the object's member data can only occur after we access the object's pointer.

when sharing memory among threads you must synchronize access so that only one thread at a time has access to the object(s). One way to do that is to create a semiphore. How to do that depends on the operating system you are using, and possibly the compiler. Do a google search for semaphore and you will probably find what you need for your os/compiler.

Hey!

Thanks for the reply. Although I agree with you that semaphores are needed, this does not seem to be the current issue.

In Debug mode, the "Access Violation" message always lists the address of this object + 4.

The following Wikipedia article indicates that it is the address of the first attribute in the object: http://en.wikipedia.org/wiki/Virtual_table

Thanks!

To provide further information, the assembly code looks as follows:

printf ("DEBUG: mRegisteredComputeFunction = %p\n", mRegisteredComputeFunction);
00417E73 mov esi,esp
00417E75 mov eax,dword ptr [this]
00417E78 mov ecx,dword ptr [eax+4] ------- CRASH -------
00417E7B push ecx
00417E7C push offset string "DEBUG: mRegisteredComputeFunctio"... (420F20h)
00417E81 call dword ptr [__imp__printf (4255DCh)]
00417E87 add esp,8
00417E8A cmp esi,esp
00417E8C call @ILT+1250(__RTC_CheckEsp) (4114E7h)

mRegisteredComputeFunction (this);
00417E91 mov esi,esp
00417E93 mov eax,dword ptr [this]
00417E96 push eax
00417E97 mov ecx,dword ptr [this]
00417E9A mov edx,dword ptr [ecx+4]
00417E9D call edx
00417E9F add esp,4
00417EA2 cmp esi,esp
00417EA4 call @ILT+1250(__RTC_CheckEsp) (4114E7h)

The crash occurs at the third line marked with "------- CRASH -------".

Can you duplicate the problem with a simple test program? According to the assembly code you posted it looks as if you pass the 'this' pointer to a non-class function or to a static function of a class.

Hi,

Thanks for your reply.

Yes, I am passing it to a static function that is implemented in a child class, which "this" pointer should be an instance of. This was an attempt for a workaround so that I do not call virtual functions because I had suspected that they might have caused this issue. Unfortunately, the issue persists in both ways.

But the thing is it even crashes before I call this static function. Interestingly enough, however, it does not crash if I simply remove the function call - although it might crash if I run the program long "enough"!

Cheers.

My guess is that you are trashing memory some place -- could be buffer overruns, out-of-bounds problem or any number of other things. One way I've used to narrow down the problem is to comment out large blocks of code until I eventually find where the program breaks. Of course the first resort is to use my compiler's debugger to inspect variable values.

Hey dude!

Thanks so much. It does seem like a buffer overrun. I temporarily increased the size of arrays allocated using new() in which data is calculated and stored, and the issue does not occur anymore!

Greg