I have the 6.1.19 C++ RTS built for exception handling on a DM648. When I am doing C++ stream I/O I have
random occurrences of stream output never returning from the ~sentry() destructor. I stepped through the
~sentry() code in <ostream> and it calls XSTD_uncaught_exception() which loops through the exception handling
stack entries but in the failure cases it gets lost and doesn't find a NULL exit pointer in the exception handling stack
I'm presuming the exception handling stack has become messed up somehow - I haven't attempted to dissect the
structure and entries to find out where. The one obvious guess is that there's a C++ file somewhere that is not
compiled for exceptions and this code can't handle the stack in that case? Or not?
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:
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.
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.
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,
TI C/C++ Compiler Forum ModeratorPlease click Verify Answer on the best reply to your question.The Compiler Wiki answers most common questions.Track an issue with SDOWP. Enter your bug id in the "Find Record ID" box.
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?
Jason KalinDo you know if there is any 3rd party product that provides this functionality now?
Jason KalinIf 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.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.