Hello David,
I created Mantis 307 to track this issue.
> 0x15d0250 (tShell): Unhandled C++ exception resulted
> in call to terminate
Do you see this behavior when spawning this program to run independently of the vxWorks shell (at a more modest priority of say 100). If this is not entangled with the vxWorks shell you might have an opportunity to get a stack trace with the "tt <task id>" command. That output might greatly assist with determining the cause of the problem.
The vxWorks shell runs typically at the very highest priority in vxWorks. Higher than the tNetTask. We have seen some strange vxWorks IP kernel behaviors when socket codes run higher than the tNetTask under vxWorks. However in this case, with the c++ exception, that might not be suspected.
Also, the CA client library spawns several auxiliary threads at priorities offset from the initiating thread, and so when running at the highest priority in the system some of these threads might not get the offsets that are requested. That might explain a change in behavior (but doesnât make us less inclined to find out what has happened and fix any bugs that might be occurring).
Jeff
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of David Maden
> Sent: Tuesday, January 22, 2008 1:16 AM
> To: [email protected]
> Subject: CA connection management - vxWorks
>
> Hi,
>
> I also have a CA connection management problem similar to the recent thread:
> Re: CA connection management problem
>
> but hopefully different enough to warrant a slightly different name.
>
> I'm trying to convert a vxWorks channel access C program from EPICS 3.13.10
> to 3.14.8. The program is intended to run once after iocInit and then exit.
> I get an exception in ca_context_destroy if the channel connection times
> out.
>
> Reducing the program to its bare essentials, it does the following:
>
> 1) Set up ca context with preemptive callbacks enabled:
>
> ca_context_create (ca_enable_preemptive_callback)
>
> 2) Call ca_create_channel specifying channel name and callback function.
>
> 3) Wait for callback function to get called:
> If callback function is called, goto step 5.
> If there is a time-out, go to step 4.
>
> 4) On time-out, call ca_context_destroy and return with error.
>
> 5) If callback function gets called, continue with calls
> to ca_get, ca_pend_io, ca_context_destroy and return with success.
>
> This runs fine if I specify a PV which is valid.
>
> If I specify an invalid channel name, I get:
>
> 0x15d0250 (tShell): Unhandled C++ exception resulted
> in call to terminate
>
> The program runs fine under Linux. Is there some problem with
> ca_context_destroy under vxWorks, which I couldn't find in the Channel
> Access Reference Manuel or the tech-talk archives? I note, for example,
> that snl programs under 3.14 are no longer able to exit. Is this related?
>
> Regards, David
> --
> [email protected]
> SLS Project
> --
- Replies:
- Re: CA connection management - vxWorks David Maden
- References:
- RE: CA connection management problem Owens, PH (Peter)
- CA connection management - vxWorks David Maden
- Navigate by Date:
- Prev:
CA connection management - vxWorks David Maden
- Next:
asynRecord immutable fields Eric Williams
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
<2008>
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
CA connection management - vxWorks David Maden
- Next:
Re: CA connection management - vxWorks David Maden
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
<2008>
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|