Trouble with TF_Cleanup call on Mac

Hi,We have been using TurboActivate for quite a while now, but wanted to investigate using TurboFloat for some of our customers that would prefer floating licenses.

When I compile and run the Example.c file (on Mac) I'm getting an EXC_BAD_ACCESS (code=1, address=0x0)/Segmentation Fault 11 when calling TF_Cleanup. I reduced the Example.c code to the following which still gives me the same error in TF_Cleanup:

//================


#include <stdio.h>


/* Support Unicode compilation and non-Windows compilation */#ifdef _WIN32    #include <Windows.h>    #include <tchar.h>#else    #define _T(x) x    typedef char TCHAR;#endif


#include "TurboFloat.h"


uint32_t tfHandle;


void TF_CC LeaseCallback(uint32_t status){    printf("LeaseCallback\n"); // This line of code doesn't get called when running this program}


int main(int argc, char* argv[]){    HRESULT hr;    // These calls all seem to work fine    tfHandle = TF_GetHandle(_T("xxxxxxxxxxxxxxxxxxxxxx.xxxxxxxx")); // Success: tfHandle != 0    hr = TF_SetLeaseCallback(tfHandle, LeaseCallback); // Success: hr == TF_OK    hr = TF_SaveServer(tfHandle, _T("127.0.0.1"), 13, TF_USER); // Success: hr == TF_OK    hr = TF_RequestLease(tfHandle); // Success: hr == TF_OK    hr = TF_DropLease(tfHandle); // Success: hr == TF_OK    // In here is where things seem to go wrong    hr = TF_Cleanup(); // (Segmentation Fault: 11 when run in terminal) (EXC_BAD_ACCESS (code=1, address=0x0) when debugging in Xcode)    return 0;}


//================

Am I missing something obvious? (hopefully) If anybody can spot a silly mistake I'm making, I'd appreciate it.

I'm using version 3.5.6 of the TurboFloat Server, and version 3.5.5.2 of the TurboFloat Library (the latest versions as of the time of this writing).

I compiled the code using both the LLVM 4.2 compiler in Xcode 4.6.1 on Mac OS X 10.8.5, and using the LLVM 5.1 compiler in Xcode 5.1 on Mac OS X 10.9.4, with the same results.

I've also tried running the TurboFloat Server for Mac on the same local computer (as shown in the code above) and also over a local network to a different computer running TurboFloat Server for Win. This also made no difference.

Thanks,Gareth

Hey Gareth, we'll look into this. We haven't been able to reproduce it on any of our Mac OS X test machines, but we'll try your partciular Xcode version Mac OS X version combo and see if that will reproduce the problem.

In the meantime you can just exclude that TF_Cleanup() call. Why? Because the memory is already being cleaned up by the system when your process exits. TF_Cleanup() is benign/useless in our example C application. The TF_Cleanup() call is really only useful if you're using TurboFloat conditionally (meaning a customer can switch between TurboActivate / TurboFloat without restarting your app) and your app is very long running (i.e. restarts less than once a year).

Thanks Wyatt,I appreciate that EXC_BAD_ACCESS error can be a bit hit-and-miss. Showing up on one computer but not another, making it very difficult to identify a cause if you're not seeing it too.

Do you think we could safely make repeated calls to TF_RequestLease and TF_DropLease without subsequent calls to TF_Cleanup in-between? Or will this leak memory?

Ideally I was hoping to be able to let users voluntarily request and drop their license whenever they wanted while keeping their application running. Some of our products run as modules within a larger application, so I liked the idea of letting them release their own license for an individual module (making it available to somebody else) without them needing to close the actual program.

If that would result in a memory leak without the call to TF_Cleanup, we can live without this option. Its more of a "nice to have" than a "must have" feature.

Well, TF_Cleanup() should really only be called once ever in an app -- when it's closing or when you'll never be using TurboFloat again for the lifetime of the process. And really you can exclude it altogether because the memory will be cleaned up when the process closes.

Ah, good to know. Thanks Wyatt. I had been working on the theory that you might be allocating some memory within the TF_RequestLease or TF_DropLease functions, that was then being deallocated from within TF_Cleanup. I was concerned that repeated calls to TF_RequestLease and TF_DropLease without a following TF_Cleanup would result in a steady memory leak.

As an aside for your next TurboFloat release, I'm not sure if you were aware, but the C example in the TurboFloat for Mac Library package actually contains Visual Studio project files. I'm not sure if you intended there to be an Xcode project, or just the source files on their own there, but I'm guessing probably not the Visual Studio project files.

I had been working on the theory that you might be allocating some memory within the TF_RequestLease or TF_DropLease functions, that was then being deallocated from within TF_Cleanup. I was concerned that repeated calls to TF_RequestLease and TF_DropLease without a following TF_Cleanup would result in a steady memory leak.

There is some memory allocated, but it's all freed up (or reused) on subsequent TF_RequestLease() or TF_DropLease() calls. Nothing builds up.

As an aside for your next TurboFloat release, I'm not sure if you were aware, but the C example in the TurboFloat for Mac Library package actually contains Visual Studio project files. I'm not sure if you intended there to be an Xcode project, or just the source files on their own there, but I'm guessing probably not the Visual Studio project files.

Yeah, we plan to put an XCode project there.

Reply
Discard post