CallChain() function extcode.h is returning corrupt handle

[john83793]

I have a sophisticated native library that uses the C function CallChain() found in extcode.h as part of error handlers to provide a detailed message to the user. The functions are called from LabVIEW using the Call Library node. This function has worked from LabVIEW functions 2016 through 2023, but for some reason is returning a corrupt handle in LabVIEW 2024 Q3. The returned handle has an array length of some large negative number, and there are no valid pointers. Here is the function that calls CallChain() and converts to a std::vector<std::string>:

std::vector<std::string> GetCallChain()
{
	std::vector<std::string> o;
	UHandle h = DSNewHClr(sizeof(int32_t));
	if (!h)
	{
		o.push_back("Unknown VI");
		return o;
	}
	if (CallChain(h) != mgNoErr)
	{
		o.push_back("Unknown VI");
		return o;
	}
	LV_LStrHandle1DHdl h2 = (LV_LStrHandle1DHdl)h;
		
	for (size_t i = 0; i < (*h2)->dimSize; i++)
	{
		LStrHandle s1 = (*h2)->elt[i];
		std::string s2 = LStrHandletoString(s1);		
		o.push_back(s2);
		DSDisposeHandle(s1);
	}
	DSDisposeHandle(h);

	return o;
}

__PRESENT

[rolfk]

CallChain() is a nasty function. It is marked TH_REENTRANT, which means it would be safe to be called from any thread but it accesses internally a global variable that defines what is the currently executing VI. And that is only valid when called from a VI context. They might have optimized something that broke this. Since the function itself is not officially documented in the External Code reference manual (but listed in the extcode.h file) its status is a little bit unclear. As undocumented function it is not guaranteed to work across different LabVIEW versions, but as declaration present in the officially distributed header files, there is certainly a bit of a reason to try to keep it working and to see this as a bug. But if it gets fixed is questionable.

One remark. GetCallChain() is the internal name of the function being called inside CallChain() in earlier versions and it is also exported in the LabVIEW export function list. I would try to give your function a bit of a more distinctive name. It's unlikely but maybe the linker gets somehow confused?

[rolfk]

I haven't really dug much deeper but just tried this VI here on LabVIEW 2020 SP1, LabVIEW 2022Q3 and LabVIEW 2024Q1. Result: Works fine in 2020 and 2022 but displays an out of memory error dialog or crashes immediately or shortly after running it in 2024Q1.

Definitely a bug, but not sure about how serious it would be classified because of the factually undocumented nature of this API.

[john83793]

@rolfk thanks for investigating!

My function GetCallChain() is mangled by the C++ compiler so I doubt that is causing a linker error.

While the CallChain() function may be technically undocumented, it is still exposed to users and has worked reliably for a long time in the past. I had a segfault in front of a client due to this error so I am really not thrilled about it failing. I doubt this is the only symptom of the underlying problem so it really should be fixed.

What is the best way to report this bug? 

[rolfk]

Well at the bottom of this page: https://www.ni.com/en/support.html is a "Open a Service Request" button. But that requires you to have an active service support contract, either a valid subscription or an active SSP for a perpetual license.

I flagged this to support as a bug, but don't hold your breath for any active resolution of this!

[rolfk]

This bug has been reported to LabVIEW R&D and assigned Bug number: 2923306

It has been flagged as candidate to be fixed in an upcoming LabVIEW release but LabVIEW versions 2024Q1 and Q3 at least will not return information in the expected format when this function is called.