Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Thu, 10 Feb 2005 22:35:35 -0600

Folks,

I reported the following problems the other day:

> I am having some strange problems running IOCs on cygwin-x86, and I
wonder
> if you might have some ideas, or could help me with this.  I have 2
> applications that I have built as static binaries: dxpApp which talks
to
> an XIA detector over the parallel port, and ccdApp that talks to a
local
> socket server to control a CCD detector.
> 
> Here are the symptoms:
> 
> - ccdApp is running fine on 3 Windows machines at my sector 13.  It is
> also running fine on a PC at Brookhaven. These machines are running
> Windows XP, either Service Pack 1 or 2.
> 
> I am having a problem running the application on another Windows
machine
> at sector 12.  It is running Windows XP service pack 2. Everything
works
> fine unless I try to run save_restore.  When save_restore tries to
open a
> file for reading, the fopen() call never returns.  When that happens
the
> SNL program in ccdApp that uses asynOctetSyncIO to talk to the socket
> server also stops communicating, it gets a timeout in asynOctetSyncIO.
> This seems like a resource deadlock.  It is completely reproducible,
so it
> does not seem to be a timing problem.
> 
> - dxpApp is running fine on a Windows XP desktop machine in my lab.
> However, when I try to run it on a Windows 2000 laptop, it
communicates
> with the hardware fine over the parallel port both before and during
> iocInit.  The IOC executes to the end of the startup script.  But at
that
> point it does not return control to the user, i.e. I don't get the
iocsh
> prompt.  ^C does nothing, the only way out is to kill the Windows
command
> shell.  The CPU is idle.  This again seems like it could be a resource
> deadlock.

The problems seemed to be related, in that file operations were blocking
when they should not.  It looked like a signaling or threading problem.

In both cases the machines with the problems were not development
machines, they were machines onto which I had copied the .exe files, .db
files, etc.  They did not have Cygwin installed on them, but I placed
cygwin1.dll in the same directory as the application .exe file.  This
allowed the application to run with no error and to "mostly" work.

Grasping at straws as to what might be wrong I installed Cygwin (the
basic package) on each of these machines.  That fixed the problem, both
IOCs now work fine!  The question now is WHY DOES THIS WORK?

- The version of cygwin1.dll that the installation places in
C:\cygwin\bin\cygwin1.dll is identical to the version I had placed in
the app\bin\cygwin-x86 directory

- The IOC runs fine either from the cygwin bash shell (which has the
cygwin bin directory in the path) or from the Windows cmd shell, which
does not have cywin\bin in the path.

- I believe that Cygwin claims that they do not modify the Windows
registry or modify things in the Windows system directories.

So why the heck does EPICS run OK after an "install" of Cygwin, but not
when just having the cygwin1.dll in the PATH?

In any event, I have a solution that works for running Windows IOCs
built with Cygwin: install Cygwin on the target machine.

Thanks to all of you that offered advice on this.

Cheers,
Mark

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System