pubsub Work Item Rss Feed

Closed Issue: Stack imbalance between SharedMemoryMgr and SharedQueue [12335]

keithh — Sat, 11 Dec 2010 02:50:50 GMT

SharedMemoryMgr uses the cdecl calling convention for five methods. The SharedQueue class that calls these methods uses the stdcall convention. As a result, there is a memory leak every time a call is made, because each side assumes the other will clean up the stack.

Here are the declarations in SharedMemoryMgr (C++):
extern INT32 __cdecl InitMemoryMgr(LPCTSTR SharedMemoryName, DWORD SharedMemorySize, PCOMMBUFFER *CommBufferIn);
extern INT32 __cdecl JoinMemoryMgr(LPCTSTR SharedMemoryName, PCOMMBUFFER *CommBufferIn);
extern INT32 __cdecl ReleaseMemoryMgr(PCOMMBUFFER *CommBufferIn);
extern INT32 __cdecl PutBuffer(LPCSTR pEventBuffer, DWORD dwEventLength, DWORD dwTimeOut, PCOMMBUFFER *CommBufferIn);
extern INT32 __cdecl GetBuffer(LPCSTR pEventBuffer, DWORD dwEventBufferLength, DWORD dwTimeOut, DWORD *pBytesRead, PCOMMBUFFER *CommBufferIn);

Here is a sample C# declaration, in SharedQueue.cs:

[DllImport(SharedMemoryMgr, ExactSpelling = true, CharSet = CharSet.Ansi)]
internal static extern ReturnCode InitMemoryMgr(
String sharedMemoryName,
UInt32 sharedMemorySize,
ref IntPtr commBuffer);

To fix this issue, the DllImportAttribute should have the calling convention specified:

[DllImport(SharedMemoryMgr, ExactSpelling = true, CharSet = CharSet.Ansi, CallingConvention = CallingConvention.Cdecl)]
internal static extern ReturnCode InitMemoryMgr(
String sharedMemoryName,
UInt32 sharedMemorySize,
ref IntPtr commBuffer);
Comments:

Bug is fixed and code checked-in.

Commented Issue: Stack imbalance between SharedMemoryMgr and SharedQueue [12335]

keithh — Sat, 11 Dec 2010 00:49:11 GMT

I updated the installs on the download page with the fix. I still need to update the source code and then I'll close this out.

Closed Issue: Mutex released when not owned [12638]

keithh — Thu, 09 Dec 2010 05:58:08 GMT

The InitMemoryMgr method creates the mutex without taking ownership:

CommBuffer->ghMutex = CreateMutex(&sa, FALSE, MUTEX_NAME);

Then, later in the function, it releases ownership in multiple places although it does not have it:

if (CommBuffer->ghEvent == NULL)
{
if(errco == 0)
errco = GENERALERRORCODE;

free((char*)lpSharedMemoryName);
ReleaseMutex(CommBuffer->ghMutex);
...
if(CommBuffer->ghMapFile == NULL || CommBuffer->ghMapFile == INVALID_HANDLE_VALUE)
{
if(errco == 0)
errco = GENERALERRORCODE;

free((char*)lpSharedMemoryName);
ReleaseMutex(CommBuffer->ghMutex);
...
if (CommBuffer->gpBuf == NULL)
{
if(errco == 0)
errco = GENERALERRORCODE;

free((char*)lpSharedMemoryName);
ReleaseMutex(CommBuffer->ghMutex);
...
ReleaseMutex(CommBuffer->ghMutex);
free((char*)lpSharedMemoryName);
return SUCCESS;

The Join method does the same thing.
Comments:

Since these lines of code are absolutely benign, I'm not inclined to remove them. I know logically they should never succeed but I'd rather leave them. These lines of code are also only executed during clean-up when a fatal error has occured.

Commented Issue: Stack imbalance between SharedMemoryMgr and SharedQueue [12335]

keithh — Mon, 06 Dec 2010 20:58:31 GMT

I will be testing the fixes later today. If all works well, I'll update Codeplex.

I'll be interested to hear how well an all .Net version of the SharedMemoryMgr works. Using shared memory from .Net via pinvokes was too costly. I haven't looked at .Net 4.0's implementation to see how efficient it might be.

Created Issue: Mutex released when not owned [12638]

DeeGee — Mon, 06 Dec 2010 20:25:18 GMT

Commented Issue: Stack imbalance between SharedMemoryMgr and SharedQueue [12335]

DeeGee — Sat, 04 Dec 2010 19:16:21 GMT

I've rebuilt the projects using .NET 4.0, and I'm in the midst of replacing SharedMemoryMgr.dll with a set of .NET classes in the SharedQueue assembly, since we now have a System.IO.MemoryMapped file class. I don't know how performance will compare, but in our environment there have been issues deploying the SharedMemoryMgr to all locations where we need it.

Commented Issue: Stack imbalance between SharedMemoryMgr and SharedQueue [12335]

Coffee_fan — Sat, 04 Dec 2010 02:15:23 GMT

Thanks DeeGee and Keith. Please keep in mind that the impact may not be low if you are sending thousands of events per second. Added my vote for a fix.

Commented Issue: Stack imbalance between SharedMemoryMgr and SharedQueue [12335]

keithh — Fri, 03 Dec 2010 16:35:59 GMT

Thanks for the find. I am making some other changes to the code and will check everything in sometime in January.

Created Issue: Stack imbalance between SharedMemoryMgr and SharedQueue [12335]

DeeGee — Sun, 24 Oct 2010 00:46:36 GMT

Closed Issue: Problem building latest source

keithh — Fri, 03 Apr 2009 17:44:37 GMT

Communicator.cs (line 1203) has a reference to SubscriptionMgr.subscriptionsLock. This doesn't seem to exist:

lock (SubscriptionMgr.subscriptionsLock)
Comments: Issue was resolved

Commented Issue: Problem building latest source

keithh — Wed, 18 Mar 2009 18:15:02 GMT

Communicator.cs (line 1203) has a reference to SubscriptionMgr.subscriptionsLock. This doesn't seem to exist:

lock (SubscriptionMgr.subscriptionsLock)
Comments: ** Comment from web user: keithh **

I updated the SubscriptionMgr.cs file to the correct version. Surprising no one had complained earlier. Thanks for letting me know.

Commented Issue: Problem building latest source

dwaterworth — Wed, 18 Mar 2009 02:35:42 GMT

Communicator.cs (line 1203) has a reference to SubscriptionMgr.subscriptionsLock. This doesn't seem to exist:

lock (SubscriptionMgr.subscriptionsLock)
Comments: ** Comment from web user: dwaterworth **

I'm seeing the same issue, the HEAD revision of svn doesn't appear match the most recent binaries, the subscriptionsLock field is not defined in SubscriptionMgr

127: internal class SubscriptionMgr : ServiceThread
128: {
129: internal static Dictionary<Guid, SubscriptionEntry> subscriptions = new Dictionary<Guid, SubscriptionEntry>();
130:
131: private DateTime nextTimeout = DateTime.UtcNow.AddMinutes(subscriptionExpirationIncrement);
132: private DateTime nextPushSubscriptions = DateTime.UtcNow.AddMinutes(subscriptionRefreshIncrement);

Commented Issue: Problem building latest source

keithh — Tue, 17 Mar 2009 22:00:14 GMT

Communicator.cs (line 1203) has a reference to SubscriptionMgr.subscriptionsLock. This doesn't seem to exist:

lock (SubscriptionMgr.subscriptionsLock)
Comments: ** Comment from web user: keithh **

It's defined on line 129 of the SubscriptionMgr.cs file. Is it in the file you have also?

Created Issue: Problem building latest source

JohnPWest — Tue, 17 Mar 2009 19:20:00 GMT

Communicator.cs (line 1203) has a reference to SubscriptionMgr.subscriptionsLock. This doesn't seem to exist:

lock (SubscriptionMgr.subscriptionsLock)