Forums

This is a fairly large project - ~2000 files.  I have a 25MByte executable and a 50MByte executable

for the full build.  This doesn't occur in the 25Mbyte build but it does in the 50MByte build.  I have checked

the added files for the 50Mbyte build and they are all built with --exceptions.  So, is there some limit

in 6.1.19 dependent on executable size that would prevent the exception handling stack examination

code from successfully completing regularly?

I am not aware of any any implementation limit on executable size with regards to the exception-handling mechanism.  The symptoms you are describing suggest to me that you are running out of heap memory or overflowing the stack, but this is just a guess.  Does the failure occur while an exception is happening?   Does it occur before main has started?

Ok, thanks.  Stack sizing is large at the moment - only a few percent is listing at peak.  I don't see any

stack overflows occurring anywhere - it doesn't look like it's going off in the weeds, it just continues looping indefinitely

Heap is only utilized around 15%/256MByte on this system.  I stepped though the code and all of the exception checks

return false, so I don't believe an exception is occurring or has occurred - it just gets into uncaught_exception() in

EDGRTS/eh_util.cpp and loops indefinitely, never finding the NULL and always showing FALSE on whether an

exception has been found in the stack.  No, this is occurring in task context quite a while after main().  Any other

things I might try?

Thanks Again, Jason

Well, an infinite loop is often a secondary effect for something else that has gone wrong.  It's still possible that the stack or the exception handling bookkeeping is being overwritten with a stray pointer somewhere.

You suggested that this problem happens randomly.  How randomly?  Does it happen at the same point during your program as long as you do not recompile?

It would help to know if the EH bookkeeping is correct with respect to the current stack backtrace.  Unfortunately, I'm not familiar with the EH implementation used in COFF ABI mode, so I don't know where to begin printing information about it.  You can call std::uncaught_exception yourself at any time; perhaps you could sprinkle some calls in your code to see if you can trigger the problem earlier.

Well, I looked through the EDG exception handling code and as far as I could see there was

no thread awareness.  This is really not spelled out anywhere in the 6.1.19 manual set that I

have.  The meaning is simple that the RTS exception handling will not work in conjunction with

DPS/BIOS.  The single exception handling stack will become confused when used in BIOS'

multi-threading environment making not only std:: uncaught_exception() not work but try/catch

in general.  This is quite catastrophic that the 2 components do not work together in regard to

exception handling and it is very unfortunate it is not prominent in the obvious manuals.

So I must ask:  Do any of the newer tool sets have exception handling which is compatible with

BIOS' threading environment - and if so, which?  I see the newer tools use a table driven mechanism

instead to improve performance but will it work correctly with DSP/BIOS and multiple threads?  I don't

see anything obvious in my 7.3.1 toolchain manual.

I can certainly try to port a 3rd party exception handling library with thread support to DSP/BIOS as

well - do you know if anything like this has already been done as it would greatly save time?

Looking through the forum, I see eventually this ~2009 post: http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/t/12567.aspx

The pertinent text is:

Georgem:

Unfortunately, you have wandered into unsupported territory.  C++ exception handling uses a data structure, not exposed to the user, to do its job.  There is only one copy of this data structure in the system.  The different tasks are all modifying this one data structure.  Changes made by one task foul up the exception handling going on in another task.  This information needs to be added to the C++ Wiki article.

Hi, George.

Are you a representative of TI, and is this TI's official answer to this problem?

If so, is the "unsupported territory" exception handling in general (which contradicts the compiler manual and release notes) or the use of it in conjunction with DSP/BIOS tasks (a rather glaring omission from the manual, IMHO)? Are there any other unsupported areas related to exceptions that we should be aware of? Does TI consider this a bug, and if so, will it be fixed and when? Can you provide me with a workaround? E.g., can I recompile part or all of the RTS source in the lib directory with a mutex around the aforementioned data structure? Can I safely use exceptions in a single task with several other non-throwing tasks running "simultaneously"?

As I mentioned previously, I guessed an unprotected data structure might be the problem and tried to exclude multiple exceptions from being thrown simultaneously with a mutex in my code (see my second post with code above). If the problem is what you describe, why did my solution not work? In particular, how do you explain the failure to destroy the exception object and thus unlock the exception handling? AFAICT, the exception handling code in throw.cpp should not be invoked until until the temporary MyException object is constructed in the statement 'throw MyException( "" );' completes, which can't happen until my exception handling mutex is available. Hence, the internal data structure should not become corrupted by multiple tasks throwing exceptions.

M

I also see the following line from this FAQ:  http://processors.wiki.ti.com/index.php/Before_asking_for_DSP/BIOS_support

However avoid using the C++ STL exception handling (try/throw/catch calls) -- they are not thread-safe. Check the last topic of this page.

It is still the case that the handling of C++ exceptions (try/throw/catch) is not thread safe.  We are in the process of adding such functionality.  But it is not yet in any wide release product.

Thanks and regards,

-George

Thanks for the info, George -

Do you know if there is any 3rd party product that provides this functionality now?

If there is an alpha version from TI, would it be possible to be a test user now?

Regards,

Jason Kalin

Jason Kalin

Do you know if there is any 3rd party product that provides this functionality now?

No.

Jason Kalin

If there is an alpha version from TI, would it be possible to be a test user now?

Yes.  I'll contact you about that separately.

Thanks and regards,

-George