Downloads  |  Buy

TA_TrialDaysRemaining returns TA_FAIL in TurboActivate 4.1 [Solved]

TA_TrialDaysRemaining returns TA_FAIL in TurboActivate 4.1 [Solved]

Postby jmcphers » August 1st, 2019, 6:46 pm

Hi,

We recently updated to TurboActivate 4.1 (from 4.0) in the development branch of our product.

For reasons we're not able to ascertain, after the update, TA_TrialDaysRemaining has started returning TA_FAIL (1) for at least expired verified trials, and possibly for other situations as well.

As it's not one of the error codes with an explanation (such as TA_E_INVALID_HANDLE, etc.), we are not sure how to diagnose the failure. Some things we have tried:

1) Removing the state folders in /var/lib/.local
2) Running an strace while TA_TrialDaysRemaining is executed to see if it's encountering permissions errors, etc.

Neither of these have been helpful. The error is returned regardless of whether the state folders are present. The strace is probably not helpful either, but just in case, here are the last few system calls before TA_TrialDaysRemaining emits an error. It looks like the last thing it does is read the state folders (successfully), then check /etc/localtime (also successfully).

[pid 2132] stat("/var/lib/.local/.c773c155981f38032a617.51222781", {st_mode=S_IFREG|0777, st_size=0, ...}) = 0
[pid 2132] open("/var/lib/.local/.c773c155981f38032a617.51222781", O_RDONLY) = 3
[pid 2132] read(3, "", 8191) = 0
[pid 2132] close(3) = 0
[pid 2132] ioctl(2, TCGETS, 0x7ffca525abf0) = -1 ENOTTY (Inappropriate ioctl for device)
[pid 2132] open("/etc/localtime", O_RDONLY|O_CLOEXEC) = 3
[pid 2132] fstat(3, {st_mode=S_IFREG|0644, st_size=127, ...}) = 0
[pid 2132] fstat(3, {st_mode=S_IFREG|0644, st_size=127, ...}) = 0
[pid 2132] read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0\0\0\0"..., 4096) = 127
[pid 2132] lseek(3, -71, SEEK_CUR) = 56
[pid 2132] read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0\0\0\0"..., 4096) = 71
[pid 2132] close(3) = 0

What else might cause TA_TrialDaysRemaining to return a generic TA_FAIL?
jmcphers
 
Posts: 25
Joined: January 18th, 2017, 9:24 am

Re: TA_TrialDaysRemaining returns TA_FAIL in TurboActivate 4.1

Postby Wyatt » August 1st, 2019, 8:36 pm

More information is needed. Exact version numbers, code you’re using including parameters passed in, whether this can be consistently reproduced on different machines.
User avatar
Wyatt
Site Admin
 
Posts: 6083
Joined: July 11th, 2007, 10:30 pm
Location: New Hampshire

Re: TA_TrialDaysRemaining returns TA_FAIL in TurboActivate 4.1

Postby jmcphers » August 2nd, 2019, 12:17 pm

> Exact version numbers

We have reproduced this with TurboActivate 4.1.5.0 and 4.1.8.1 on Linux.

> code you’re using including parameters passed in

Here's the actual invocation from our source code:

HRESULT hr = ::TA_TrialDaysRemaining(handle(), trialFlags_, pDaysRemaining);

handle() returns the handle (obviously) trialFlags_ is TA_VERIFIED_TRIAL in this case, and pDaysRemaining is a pointer to a uint32_t.

> whether this can be consistently reproduced on different machines.

Yes, we have reproduced the problem on three different machines running a variety of Linux operating systems (one on Fedora 28, one on Ubuntu 16, not sure about the last).
jmcphers
 
Posts: 25
Joined: January 18th, 2017, 9:24 am

Re: TA_TrialDaysRemaining returns TA_FAIL in TurboActivate 4.1

Postby Wyatt » August 2nd, 2019, 2:27 pm

If I were to guess I'd say it has to deal with messing with internal state files. Don't change them, delete them, replace them, etc. Why? Because there are a handful of files modified in-tandem. And the internal details change.

If you mess with things in unexpected ways, TurboActivate won't try to guess what you did. It will just throw up its hands and say "no trial for you" (TA_FAIL or TA_E_EXPIRED). Which is what you would want in the real world anyway.
User avatar
Wyatt
Site Admin
 
Posts: 6083
Joined: July 11th, 2007, 10:30 pm
Location: New Hampshire

Re: TA_TrialDaysRemaining returns TA_FAIL in TurboActivate 4.1

Postby jmcphers » August 2nd, 2019, 2:35 pm

Wyatt wrote:
> If I were to guess I'd say it has to deal with messing with internal state
> files. Don't change them, delete them, replace them, etc.

This can't be the problem because we've observed it on 2 systems with almost-pristine configurations. Only after getting the error repeatedly on multiple systems did we try removing the files (thinking that perhaps something in them might have become corrupted or invalid).
jmcphers
 
Posts: 25
Joined: January 18th, 2017, 9:24 am

Re: TA_TrialDaysRemaining returns TA_FAIL in TurboActivate 4.1

Postby bkendall » September 13th, 2019, 2:22 pm

We're getting the same error after trying to upgrade from TurboActivate v4.0.9.7 to TurboActivate v4.1.9.0.

We've reproduced the error in macOS 10.14.6, Windows 7, and CentOS 7.6. The macOS system was in a state where a trial started by TurboActivate v4.0.9.7 was already expired. The latter two systems were both in a pristine state where no version of TurboActivate had been used previously and no trial had been started.

We're using the static version of TurboActivate as our software is a plug-in that runs within the context of another application.

So far we've only been using node locked licenses and trials, but we're starting to implement floating licenses. It seems like the current version of TurboFloat is incompatable with TurboActivate v4.0.9.7, but because of this issue we're unable upgrade TurboActivate.

Until we can figure out why we're unable to successfully call TA_TrialDaysRemaining in the latest version of TurboActivate, we're not able to make progress on floating licensing.

As a stopgap, is there somewhere we can download TurboFloat v4.0.9.7?
bkendall
 
Posts: 5
Joined: February 16th, 2019, 1:42 pm

Re: TA_TrialDaysRemaining returns TA_FAIL in TurboActivate 4.1

Postby Wyatt » September 13th, 2019, 2:30 pm

Firstly, exactly the parameters and error codes you get are needed. Also, sample code. See: https://wyday.com/limelm/help/faq/#useful-reports

When we get a partial picture we need to fill in a bunch of holes with assumptions which may or may not be correct.


>> "We're getting the same error after trying to upgrade from TurboActivate v4.0.9.7 to TurboActivate v4.1.9.0."

>> "We've reproduced the error in macOS 10.14.6, Windows 7, and CentOS 7.6. The macOS system was in a state where a trial started by TurboActivate v4.0.9.7 was already expired. "


The error code handling internally in TA 4.0 vs 4.1+ is slightly different. Namely, if you have an expired trial, TurboActivate will tell you about it earlier.

So... it sounds like everything is working correctly. You'll just need to alter the code in your app to handle the "expired" error code.

But, again, tell us the code you're using, the parameters you're passing, the return codes for every function called, what you expect to happen, etc., etc. and we can tell you exactly what to fix.
User avatar
Wyatt
Site Admin
 
Posts: 6083
Joined: July 11th, 2007, 10:30 pm
Location: New Hampshire

Re: TA_TrialDaysRemaining returns TA_FAIL in TurboActivate 4.1

Postby bkendall » September 13th, 2019, 4:11 pm

I think I now have an idea of what we were doing wrong. We were relying on some undocumented behavior of TurboActivate v4.0.9.7 that no longer works in 4.1.

We need to determine whether or not the user has already started a trial before we call TA_UseTrial. Our software has a free mode and a paid mode with additional features. We want to allow users of the free mode to begin a trial of the paid mode at any time, possibly after using the free mode for quite a while.

When the software launches, if the user has started the trial, we want to remove the option to start a trial and display how many days they have remaining.

However, if we call TA_UseTrial at startup, that will start the trial if it hasn't started yet.

The way we dealt with this with TurboActivate v4.0.9.7 was with the following function:

/// Code begins here

#define LIME_TRIAL_FLAGS (TA_VERIFIED_TRIAL | TA_USER)

bool isTrial() {
uint32_t ignored = 0;

// NB: limeHandle() returns a valid handle
HRESULT result = TA_TrialDaysRemaining(limeHandle(), LIME_TRIAL_FLAGS, &ignored);

if (result != TA_OK && result != TA_E_MUST_USE_TRIAL) {
// handle unexpected error here
}

return result == TA_OK;
}

/// Code ends here

We were relying on the fact that TA_TrialDaysRemaining would return TA_E_MUST_USE_TRIAL when the trial has not started. In TurboActivate v4.0.9.7, TA_TrialDaysRemaining returned TA_OK if a trial has been started by a previous instance of our software but TA_UseTrial had not yet been called for the current instance.

In TurboActivate 4.1.x, it seems that TA_TrialDaysRemaining returns TA_FAIL if TA_UseTrial has not been called for the current instance of our software, regardless of whether a trial has been started by a previous instance.

And, if TA_UseTrial has been called and returned TA_E_TRIAL_EXPIRED, TA_TrialDaysRemaining seems to return TA_FAIL.

Are both of these intended behavior? If so, then I'm confused about the circumstances in which TA_TrialDaysRemaining would return TA_E_MUST_USE_TRIAL. Also, it seems to contradict the documentation which states that TA_TrialDaysRemaining indicates there are 0 days remaining if the trial has expired.

In fact, if I recall correctly, we knew we were relying on undocumented behavior here. But we do need to know whether or not the user has started a trial without having to call TA_UseTrial and we couldn't figure out any other way to determine that.

Is there a recommended way for us to find out if a trial has started without using TA_UseTrial?
bkendall
 
Posts: 5
Joined: February 16th, 2019, 1:42 pm

Re: TA_TrialDaysRemaining returns TA_FAIL in TurboActivate 4.1

Postby Wyatt » September 16th, 2019, 11:39 am

>> "Is there a recommended way for us to find out if a trial has started without using TA_UseTrial?"

No, there's currently no way to determine that. We just recommend following the examples. Namely, check if activated / genuine, if not check trial days remaining, and show some combination of interface options depending on the needs for your business.


>> "TA_E_MUST_USE_TRIAL when the trial has not started"

You were depending on undefined internal behavior. TurboActivate did / does return TA_E_MUST_USE_TRIAL, but it doesn't *just* return that.


>> "And, if TA_UseTrial has been called and returned TA_E_TRIAL_EXPIRED, TA_TrialDaysRemaining seems to return TA_FAIL."

Under certain circumstances, yes. So, you'll need to handle the TA_E_TRIAL_EXPIRED rather than just barreling through to TA_TrialDaysRemaining().
User avatar
Wyatt
Site Admin
 
Posts: 6083
Joined: July 11th, 2007, 10:30 pm
Location: New Hampshire

Re: TA_TrialDaysRemaining returns TA_FAIL in TurboActivate 4.1 [Solved]

Postby bkendall » September 27th, 2019, 11:25 am

Thanks for the response. We've dealt with this issue by storing a flag in a separate settings file that determines whether or not the trial has started. We're a little concerned that it might in some cases get out of sync with TurboActivate's state but that's not too big of a deal since it won't actually allow the user to reset their trial.

Would you consider adding a function to TurboActivate that checks to see whether the trial has started? That would be very helpful for our use case, and likely other use cases as well.
bkendall
 
Posts: 5
Joined: February 16th, 2019, 1:42 pm


Return to LimeLM, TurboActivate, & TurboFloat Support