Crash on ExtendTrial()

Hey Philippe,

This bit of the stack trace looks fishy:

6 libTurboActivate.dylib 0x00000001002aacff SetCurrentProduct + 35417 libTurboActivate.dylib 0x00000001002ac0ad SetCurrentProduct + 85798 libTurboActivate.dylib 0x00000001002a910f ExtendTrial + 110

ExtendTrial() doesn't call SetCurrentProduct(), which means you're calling it from another thread in your app. Don't do that. TurboActivate isn't thread safe. All the functions should be run from a single thread (or if you're using multiple threads then use mutex locks around the TurboActivate calls).

Thank you.I think you should say this somewhere, especially as the Windows library is multi-threaded, I assumed that Mac library was thread-safe ... By the way, why don't you make it thread-safe on Mac too ?

However, please double check this crash on 64 bits applications : I asked my users to run my product in 32 bits mode, and the crash didn't occur any more.Moreover, there is no reason that my product calls TurboActivate in 2 separate threads at the same time, and the problem appeared very recently (when my product went 64 bits ready, and with new LimeLM version). Never had a crash with TurboActivate before.So please double check.

On my side I'll use mutex to guarantee thread-safety in my product.

I think you should say this somewhere

You're absolutely right. We could never think of a place to put this that customers would read it. That's the tricky part. Thus, we'll just make TA thread safe.

, especially as the Windows library is multi-threaded, I assumed that Mac library was thread-safe

The Windows version of TurboActivate isn't thread safe either. No platform is -- not yet.

By the way, why don't you make it thread-safe on Mac too ?

All platforms will be thread safe after the TurboFloat release. Likely TA 3.4.x.

However, please double check this crash on 64 bits applications : I asked my users to run my product in 32 bits mode, and the crash didn't occur any more.

I did double check it. ExtendTrial() never calls SetCurrentProduct() -- in other words the stack trace posted is impossible if TurboActivate is called from a single thread. A well timed SetCurrentProduct() from another thread can cause a crash if you're in the middle of another call.

Also, 32-bit isn't crashing because this is a timing issue. In other words, this crash can happen on 32-bit too, you're just not seeing it because of lucky timing.

Hello,

One of my users got a similar crash with IsGenuine() :0 libsystem_kernel.dylib 0x9877c9c6 __pthread_kill + 101 libsystem_c.dylib 0x9acf2f78 pthread_kill + 1062 libsystem_c.dylib 0x9ace3ce3 __abort + 1983 libsystem_c.dylib 0x9ace3c1d abort + 2314 libsystem_c.dylib 0x9ad45e61 free + 4485 libTurboActivate.dylib 0x001c5343 0x1c3000 + 90276 libTurboActivate.dylib 0x001c522b 0x1c3000 + 87477 libTurboActivate.dylib 0x001d49e6 0x1c3000 + 721668 libTurboActivate.dylib 0x001da147 IsGenuine + 141

There is no other thread using TurboActivate, it's happening on every IsGenuine() call with TA 3.3.X.Do you know what it means ?

By the way, TA 3.4 is now thread-safe, right ?

Thank you. Philppe

By the way, TA 3.4 is now thread-safe, right ?

No. After TurboFloat we'll make a release of TA that is thread safe.

There is no other thread using TurboActivate, it's happening on every IsGenuine() call with TA 3.3.X.Do you know what it means ?

This looks like the other crash you were having. Multiple calls to the same function that should be only called once or not at all. Are you *sure* you're not using threading? Your use of SetCurrentProduct() implies a use of multiple products in one app, and thus multiple threads in the app.