internal error: backend signals

internal error: backend signals


I tried porting my C++ application to STM and received the following error along with a few warnings:

tx_warning: World.cpp(303): a non tm_callable/tm_waiver intrinsic function 'memcpy' called inside __tm_atomic section
tx_warning: World.cpp(246): a non tm_callable/tm_waiver intrinsic function '_Unwind_Resume' called inside __tm_atomic section
(0): internal error: backend signals

Any idea on what might cause the internal error? And/or if the warnings could be ignored?

8 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Next update of the STM compiler should address the warning. For the internal error I need a test case to identify the error. Is it possible for you to post world.cpp without exposing any proprietary information.


And/or if the warnings could be ignored?
The warnings are telling you that you are calling (possibly implicitly, for instance the mecpy might be the result of structure assignment of large stuctures) functions inside a transaction which have not been instrumented, and can therefore make memory accesses which will not obey the transactional protocols. As a result the isolation properties of the transaction may be violated (another transaction might see intermediate values caused by this transaction), or this transaction might fail to retry when it ought to (because it doesn't realise that it has read inconsistent values which were written by another concurrent transaction).

In the upcoming release the system will behave safely in such cases (because it will serialize the transactions, turning the correctness problem into a potential performance problem), but in the current release the compiler just ignores the issue, and lets the code run as though the functions had been decorated with tm_waiver.

Like Ravi I can't tell what the cause of the internal error is, but it may be related to exception handling (which you seem to be doing based on the call to _Unwind_Resume).

I hope that helps.

I actually don't know where the call to _Unwind_Resume is happening. Is that internal in STM?

Also, would it help if I wrap around memcpy in another function that's tm_callable?

Finally, the code I'm using is actually freely available on The only thing I'm doing is parallelizing the World::update() function by putting a __tm_atomic around the outer and inner loops in that function.

Thanks for the help so far. I'm looking forward to your upcoming release. When is that scheduled for?

_Unwind_Resume is part of exception handling mechanism on Linux. Whenever you have try/catch or objects are constructed, the compiler generates code so if an exception occurs, during the unwinding phase searching for a catch handler, the objects which go out of scope can be destroyed.

Next update of the STM compiler recognizes _Unwind_Resume and not generate any warning

Iadded __tm_atomic inWorld::update() for the 2 loops as you suggested, the soon to be released compiler did not fail with an internal error.The expected release is around April 08

Would it be possible to get a Beta version of the compiler to try this out with?

Would it be possible to get a Beta version of the compiler to try this out with?

Sorry, that's impossible, because What-If already is effectively alpha testing! (There is no guarantee that this technology will ever appear as a product).

We'reworking to get the bits out as fast as possible to What-If, and there is no faster technique we can (acceptably to our management ) use to get anything out sooner than is already scheduled.

So, I'm afraid you'll just have to wait.

Leave a Comment

Please sign in to add a comment. Not a member? Join today