Warning: object 'kCommandProcessorBoss' has a really high ref count

[#1]

I am trying to create Indesign(indd) file programtically. This has lot of graphics, after writting some vector graphics I am getting following warnning always for each next processing

Warning: object 'kCommandProcessorBoss' has a really high ref count

Is there any way to reset this ref count?

OR any other option to get rid of this warning 

Thanks

Chetan

[#2]

Read about the basics of reference counters, difference of AddRef/Release, Get* vs. Query* methods.

Then examine your code where it accesses that boss, it is likely using a pointer variable where it should use an InterfacePtr.

[#3]

You are leaking object reference in most probability. Follow Dirk's advice, also it would be beneficial to use debug version of InDesign it gives a report on the memory leaks in terms of interface and boss leaks that helps in debugging such issues.

-Manan

[#4]

Hmm, that error message, mentioning a boss class, already sounds like an assert from the debug build.

[#5]

Thanks Dirk, Manan

Here is part of code where I am using command, there are other places also where I call ProcessCommand but most of the code is similar, can you please tell me if anything wrong I am doing here 

ErrorCode MyClass::ApplySplineAttributes()
{
	ErrorCode status = kFailure;
	do {
		ASSERT(fIApplyMultAttributesCmdData);
		if (!fIApplyMultAttributesCmdData) {
			break;
		}
		InterfacePtr<ICommand> gfxApplyMultAttributesCmd(fIApplyMultAttributesCmdData, UseDefaultIID());
		ASSERT(gfxApplyMultAttributesCmd);
		if (!gfxApplyMultAttributesCmd) {
			break;
		}
		gfxApplyMultAttributesCmd->SetItemList( UIDList(fSplineUIDRef));
		status = CmdUtils::ProcessCommand(gfxApplyMultAttributesCmd);
		ASSERT_MSG(status == kSuccess, "kGfxApplyMultAttributesCmdBoss failed");
		if (status != kSuccess) {
			break;
		}
	} while(false);
	fIApplyMultAttributesCmdData.reset(nil);
	return status;
}

[#6]

This does not show how you initialize your fIApplyMultAttributesCmdData InterfacePtr. I'd usually keep CreateCommand and ProcessCommand in one method, but in some scenarios (multiple attribute changes in one command combined) it actually makes sense.

Assuming (as in: I don't know without further look) that the cmd boss holds a reference to kCommandProcessorBoss somewhere in the base implementation. Otherwise, kCommandProcessorBoss is a different beast.

Before you dive in too deeply, make sure you have ITK symbols installed and watch out from within the assert, maybe you can identify the overflowing counter from the debugger and set a watchpoint.

[#7]

To me this method looks fine. I suspect fIApplyMultAttributesCmdData, the way it is being created should hold the key to this problem. My guess would be that it's ref count is being increased somewhere in the code which might not be very obvious hence causing the leak

-Manan 

[#8]

Thanks Manan,

This is the function of same class where I am creating fIApplyMultAttributesCmdData

void MyClass::AddAnAttribute(IPMUnknown* attribute)
{
	do {
		if (fIApplyMultAttributesCmdData == nil) {
			// Create a command that can change graphic attributes.
			InterfacePtr<ICommand> gfxApplyMultAttributesCmd(CmdUtils::CreateCommand(kGfxApplyMultAttributesCmdBoss));
			ASSERT(gfxApplyMultAttributesCmd);
			if (!gfxApplyMultAttributesCmd) {
				break;
			}
			InterfacePtr<IApplyMultAttributesCmdData> applyMultAttributesCmdData(gfxApplyMultAttributesCmd, UseDefaultIID());
			ASSERT(applyMultAttributesCmdData);
			if (!applyMultAttributesCmdData) {
				break;
			}
			fIApplyMultAttributesCmdData = applyMultAttributesCmdData;
		}
		fIApplyMultAttributesCmdData->AddAnAttribute(attribute);
	} while(false);
}

[#9]

This also looks ok. But then, it is not directly dealing with a kCommandProcessorBoss.

Do you maybe have any unbalanced command sequences around? IMO this pseudo-goto error handling style of the SDK samples (the do-break-while-false loops) is asking for such trouble, even more than a honest goto, that must be among the most controverse code style policies at Adobe. In my code they would not even see the first compile. But then, we're still poking around in the dark so it could be anything else including a different plug-in.

As mentioned above I'd pursue this from a debugger. Maybe start from the assert, locate the counter variable using ITK symbols or wild guess from assembly code voodoo, watchpoint on it and see where the references pile up.

[#10]

I see this code is almost the same as the SDK sample it is referring to. Assuming that the SDK sample does not have any issues, I suggest focussing on the part that you have changed from the SDK. That should hold the key and be faster in terms of getting near the code that is the culprit. All that Dirk mentioned is very sound advice, add that to what I suggested, and you should have a plan of action.

-Manan