Experimental Physics and
Industrial Control System

David Maden <[email protected]> · Wed, 23 Jan 2008 09:22:21 +0100

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: [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

VxWorks-problem.tgz

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System