• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 99 subscribers
  • Views 1180 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CERuntime_exit() and DSPLink

Frank Talbot
Intellectual 560 points

I'm having some mysterious behavior occur when shutting down my application.  It seems to be tied with shutting down CodecEngine 2.21, and we did not have this problem when using CodecEngine 1.10. 

 
We have a modular, multi-platform application that collects video, among other things, and its behavior is defined at startup with a list of shared objects to load to give it the functionality we need for any particular scenario.  The video recording capability on our DM6446-based hardware is encapsulated in a shared object that utilizes the CodecEngine API.
 
Things go well while the application is running, and we are able to record video without any problems.  The problem surfaces when the application closes: when Engine_close() gets called from within the shared object, I get a "terminate called without an active exception.  Aborted."
 
The identical code worked flawlessly when using CodecEngine 1.10 on this same hardware.  The fact that the CE API calls were encapsulated in a shared object didn't seem to bother it.  Standalone, monolithic code using CodecEngine 2.21 runs fine.  It would seem to indicate that something in Engine_close() in this version of the API doesn't play well inside a shared object context.
 
I eventually ended up building a test object to track down what was going wrong.  It simply calls CERuntime_init() when the object opens and then CERuntime_exit() when the object closes.  When CERuntime_exit() is called, the same error happens as when Engine_close() was called before (according to the output with CE_DEBUG=3).  If I don't call CERuntime_exit(), the application hangs after return-from-main and never closes.

I came across http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg06561.html and thought that this might be related to the problem, and that I should disable the signal handler.  Disabling the signal handler in the kernel module is no problem, but doing so in the IPC seems tricky in that I'm not sure how to rebuild ipc_dsplink_6446.av5T, which I assume my application needs to link with at some point.

We're using a 2.6.28-davinci-git kernel, CodecEngine 2.23 (problem still exists), and the OE/Angstrom distribution/toolchain.

Any insight is greatly appreciated.

<EDIT>

I should add that I believe this is a DSPLink issue due to the output from a trace:

@14,356,108us: [+0 T:0x400209b0 S:0x03cf87cc] OG - Global_exit> enter
@14,357,444us: [+2 T:0x400209b0 S:0x03cf87cc] OG - Global_exit> calling
function *0x4046c144()...
@14,358,795us: [+2 T:0x400209b0 S:0x03cf87cc] OG - Global_exit> calling
function *0x4046de64()...
@14,360,221us: [+0 T:0x400209b0 S:0x03cf879c] OM - Memory_free>
Enter(0x10d640, 0x18)
@14,361,470us: [+0 T:0x400209b0 S:0x03cf879c] OM - Memory_free> return
(0x1)
@14,362,705us: [+0 T:0x400209b0 S:0x03cf879c] OM - Memory_free>
Enter(0x10db18, 0x18)
@14,363,952us: [+0 T:0x400209b0 S:0x03cf879c] OM - Memory_free> return
(0x1)
@14,365,187us: [+0 T:0x400209b0 S:0x03cf879c] OM - Memory_free>
Enter(0x10db38, 0x18)
@14,366,513us: [+0 T:0x400209b0 S:0x03cf879c] OM - Memory_free> return
(0x1)
@14,367,753us: [+2 T:0x400209b0 S:0x03cf87cc] OG - Global_exit> calling
function *0x40476460()...
@14,369,019us: [+2 T:0x400209b0 S:0x03cf87cc] OG - Global_exit> calling
function *0x404709d0()...
@14,370,472us: [+2 T:0x400209b0 S:0x03cf87cc] OG - Global_exit> calling
function *0x404715a4()...
@14,371,746us: [+2 T:0x400209b0 S:0x03cf87cc] OG - Global_exit> calling
function *0x40473c34()...
@14,373,007us: [+2 T:0x400209b0 S:0x03cf87cc] OG - Global_exit> calling
function *0x40471958()...
@14,374,277us: [+0 T:0x400209b0 S:0x03cf879c] OP - doCmd> Enter
(cmdId=3, proc=0x0)
@14,375,657us: [+0 T:0x400209b0 S:0x03cf878c] ti.sdo.ce.osal.Sem -
Entered Sem_post> sem[0x10d5e0]
@14,377,130us: [+0 T:0x40cee490 S:0x40cedd34] ti.sdo.ce.osal.Sem -
Leaving Sem_pend> sem[0x10d5e0] status[0]
@14,377,381us: [+0 T:0x40cee490 S:0x40cedd54] OP - getCmd_d> Exit
(result=3)
@14,377,561us: [+0 T:0x40cee490 S:0x40cedd44] ti.sdo.ce.osal.Sem -
Entered Sem_post> sem[0x10d5f8]
@14,377,743us: [+0 T:0x40cee490 S:0x40cedd54] ti.sdo.ce.osal.Sem -
Leaving Sem_post> sem[0x10d5f8]
terminate called without an active exception

...it seems to be blowing up from within the DSPLink daemon thread context.


</EDIT>

 

  • 0
    Prodigy 40 points

    I was wondering if you ever found the answer to this problem, since I have an application that is doing the exact same thing ???

  • 0 in reply to Andrew Van Uitert
    Intellectual 560 points

    No, I never did, unfortunately.  Best I could come up with, is that it seems related to C++ exceptions.  Removing a section of code that uses the Boost C++ library's shared memory objects made the error go away in  a separate application.

     

    We got around the problem by making a stand-alone daemon that handles all of the CodecEngine calls, and communicates via shared memory and named semaphores with our application, which now has no CodecEngine code in it.

     

    I'm curious, what is your setup like?

  • 0 in reply to Frank Talbot
    Prodigy 40 points

    We reduced our setup to a quick test app that just does an CERuntime_init followed by a Engine_open then an Engine_close then a CERuntime_exit, and the test app wont exit.

    Our real application is doing some audio decoding, and is fairly straightforward in that it is almost as simple as the test app in its setup, with a little more to it.

    In our deployment of the app, we have two flavors. One that usses the DSP hardwre, and anoher where the codec engine is running on the arm processor.  Interestingly enough, the application with the codec engine running on the arm will exit jsut fine.  When we are going through DSPLink, we see the hang.

    Our best theory so far is that it is related to the use of DSPLink jsut as you had concluded.

    We are still in the midst of tracking it down with some help from TI, so if I find out what the fix is I will post it back on this thread.

     

  • 0
    Prodigy 10 points

    Hello all.  I work with Andy and we have come up with a solution.  We currently are mixing C and C++  (CE2 in C) our application is C++.

    We also saw the same problems with calling the CERuntime_exit.  The key to the problem was the error msg: terminate called without an active exception.

    It boiled down to any STL class instance in one of our .cpp files (not main.cpp).  We compiled all our cpp code with the default of -fexceptions, by changing this to -fno-exceptions for our g++ compiler the terminate called without an active exception, stopped happening and our application exits and restarts without any problems.

    I hope this is helpful to you, as it solved our problem.

  • 0 in reply to Craig Matsuura
    Intellectual 560 points

    Ah, that is interesting.  Unfortunately, we use exceptions in our C++ application, quite extensively... so compiling with -fno-exceptions would be impractical for us.

    Does this also imply that an exception is actually being thrown somewhere and causing the crash/hang?

  • 0 in reply to Frank Talbot
    Prodigy 20 points

    Hi Frank,

    Was a solution ever found for this ? I've a similar situation using an OMAP - everything works until I exit the program and then I get a message "terminate called without an active exception" and my program fails to exit. It only happens if I'm using DSP link and seems independent of whether I cleanup and close DSP link or not.

  • 0 in reply to Doug Gillespie
    Intellectual 560 points

    Hi Doug,

    Unfortunately, no, I never could find a satisfactory solution other than the one stated above where we had to move the CE interface to a separate application and let it communicate over shared memory to our main application.  I suspect, however, that compiling the CE interface as a separate library that could subsequently be linked in to our main application would also have the same effect, as long as the library was compiled with -fno-exceptions.

    This is a very frustrating situation and I wish I had a better solution for you.

  • 0
    TI__Prodigy 15 points

    Hi everyone,

     

    I recognize this is a somewhat stale thread but I thought I'd post what we found in hopes of helping others in the future. 

    I a project using CE and exceptions we found that we also got the following error:

    terminate called without an active exception

    We found that calls to pthread_exit and pthread_cancel which resulted in unwinding the stack worked fine in c-only compilations, but with c++ exceptions we'd see the above error.  One compiler manual offered the following counsel:

    "When using STL containers as local objects, the destructor will not get called when pthread_exit() is called, which leads to a memory leak. Do not call pthread_exit() from C++. Instead you must throw or return back to the thread's initial function. There you can do a return instead of pthread_exit().

    Pthread library has no knowledge of C++ stack unwinding. Calling pthread_exit() for will terminate the thread without doing proper C++ stack unwind. That is, destructors for local objects will not be called. (This is analogous to calling exit() for single threaded program.)"  http://h21007.www2.hp.com/portal/download/files/unprot/aCxx/Online_Help/threads.htm

    Given a requirement for exceptions with C++ we decided to look at reworking the pthread_exit and pthread_cancel calls in the system.  Eliminating those calls resolved the termination.

    Hope this helps,

    Dave