FbxExporter seemingly not releasing file handles

Anonymous

FbxExporter seemingly not releasing file handles

Anonymous
Not applicable

I'm trying to test my code that uses the FBX SDK. Since the SDK is closed source, I can't effectively spoof the file i/o that backs it, and I'm not keen on faking the entire surface area of the SDK that I use. So I figure I need to deal with actually creating files on the hard drive, and then reading them back in with my test, and deleting them as soon as the tests complete. This is non-ideal, but it's better than any alternative I've been able to come up with.

 

But this is presenting a problem. At the end of the test, when I go to delete the files, I can't because "The process cannot access the file because it is being used by another process". This is despite the fact that I've already called Destroy() on the FbxExporter, and then also called Destroy() on the FbxManager. The files remain "in use" until the process ends.

 

This would imply that the FbxExporter is somehow losing the handles, instead of cleaning them up properly. Is there anything I can do about this?

0 Likes
Reply
521 Views
4 Replies
Replies (4)

vincent.haubruge
Autodesk
Autodesk

Hi,

 

Could you specify the FBX SDK version?

 

Thank you for your help.

 

Vincent



Vincent Haubruge
0 Likes

Anonymous
Not applicable

Sorry... It's the C++ FBX SDK 2017, on Windows 7.

0 Likes

regalir
Autodesk
Autodesk

Hi,

 

would it be possible to get a snippet of the code you are executing that is causing you trouble? I tried with the following code:

 

	FbxExporter* lExporter = FbxExporter::Create(lSdkManager, "");
	FbxString filename("C:\\temp\\tmp\\dummy.fbx");
	lExporter->Initialize(filename.Buffer(), 1, lSdkManager->GetIOSettings());
	lExporter->Export(lScene);
	lExporter->Destroy();

	int res = remove(filename.Buffer());

and everything looked normal. The lExporter->Destroy() does, ultimately, call fclose(mFilePtr) and the remove() function returned 0 as expected.

I am confident the FBX SDK properly releases the file handle once it is done using it but, maybe, your code forces the FBX SDK to take an "unconventional" execution path and I really would like to understand it and, if necessary, find a fix for it.

 

Thanks

0 Likes

Anonymous
Not applicable

Uh, so I'm very confused now.

 

I had actually already moved on to an alternate solution, because I didn't have time to wait for a fix. And I foolishly hadn't saved my previous code. So I went to re-create it, so I could post it here. And in doing so, I can't reproduce the bug anymore.

 

So, I guess it's not an issue anymore? Yay?

 

I'll let you know if it re-emerges, and I can't isolate it to some mistake of mine.

0 Likes