Re: CA connection management - vxWorks

[David Maden <David.Maden@psi.ch>]

Hi Jeff,

The problem persists, even if I spawn the program. I attach a tar-ball with 
the program source, a "prettified" console log from the compilation of the 
program, and the VxWorks console log obtained when running the program, 
including a stack trace.

I hope this helps.

Regards, David

Jeff Hill wrote:
> 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: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov]
> > On Behalf Of David Maden
> > Sent: Tuesday, January 22, 2008 1:16 AM
> > To: tech-talk@aps.anl.gov
> > 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
> > --
> > David.Maden@psi.ch
> > SLS Project

Attachment: VxWorks-problem.tgz
Description: GNU Unix tar archive