Experimental Physics and
Industrial Control System

 

OK, that patch let me get the example application to compile.

 

However, there are problems when running it.  The behavior I see is different on windows-x64 and windows-x64-static.

 

- On windows-x64 the IOC application runs OK but when I try to exit the application I get the error I reported in my first message today, i.e. epicsSocketDestroy errors.  ^C will not kill the IOC application, I need to use the Task Manager.  This is a serious problem, and as I said earlier it affects other IOCs such as simDetector.

 

J:\epics\devel\example\iocBoot\ioctest>..\..\bin\windows-x64\test.exe st.cmd

#!../../bin/windows-x64-static/test

< envPaths

epicsEnvSet("IOC","ioctest")

epicsEnvSet("TOP","J:/epics/devel/example")

epicsEnvSet("EPICS_BASE","H:/epics-devel/base-7.0.1")

cd "J:/epics/devel/example"

## Register all support components

dbLoadDatabase "dbd/test.dbd"

test_registerRecordDeviceDriver pdbbase

## Load record instances

dbLoadTemplate "db/user.substitutions"

dbLoadRecords "db/testVersion.db", "user=rivers"

dbLoadRecords "db/dbSubExample.db", "user=rivers"

#var mySubDebug 1

#traceIocInit

cd "J:/epics/devel/example/iocBoot/ioctest"

iocInit

Starting iocInit

############################################################################

## EPICS R7.0.1.1

## EPICS Base built Dec 16 2017

############################################################################

iocRun: All initialization complete

2017-12-27T14:52:54.595 No broadcast addresses found or specified - empty address list!

## Start any sequence programs

#seq sncExample, "user=rivers"

epics>

epics>

epics>

epics>

epics> exit

epicsSocketDestroy: failed to close a socket because "WINSOCK Error 10093"

2017-12-27T14:53:16.250 Receive thread for UDP socket 0.0.0.0:0 has not exited.

epicsSocketDestroy: failed to close a socket because "WINSOCK Error 10093"

2017-12-27T14:53:21.296 Receive thread for UDP socket 164.54.160.31:5076 has not exited.

epicsSocketDestroy: failed to close a socket because "WINSOCK Error 10093"

2017-12-27T14:53:26.333 Receive thread for UDP socket 0.0.0.0:5076 has not exited.

epicsSocketDestroy: failed to close a socket because "WINSOCK Error 10093"

 

 

On windows-x64-static the IOC crashes immediately, without even starting to execute the st.cmd file:

 

J:\epics\devel\example>make -sj clean uninstall

 

J:\epics\devel\example>make -sj

devXxxSoft.c

xxxRecord.c

testHello.c

dbSubExample.c

devtestVersion.c

initTrace.c

testMain.cpp

test_registerRecordDeviceDriver.cpp

../devtestVersion.c(27) : warning C4267: '=' : conversion from 'size_t' to 'epicsUInt32', possible loss of data

../xxxRecord.c(211) : warning C4244: '=' : conversion from 'epicsFloat64' to 'float', possible loss of data

../xxxRecord.c(211) : warning C4244: '=' : conversion from 'epicsFloat64' to 'float', possible loss of data

Appending initTrace.obj

Appending testHello.obj

Appending devtestVersion.obj

Appending dbSubExample.obj

Appending devXxxSoft.obj

Appending xxxRecord.obj

 

J:\epics\devel\example>cd iocBoot\ioctest

 

J:\epics\devel\example\iocBoot\ioctest>..\..\bin\windows-x64-static\test.exe st.cmd

 

At that point Windows pops up a dialog box telling me that test.exe has crashed.  Opening the Visual Studio debugger tells me that it is an access violation on address 0.

 

Is there a test in EPICS base that instantiates the example IOC?

 

Mark

 

 

> -----Original Message-----

> From: [email protected] [mailto:[email protected]] On Behalf

> Of Andrew Johnson

> Sent: Wednesday, December 27, 2017 1:04 PM

> To: [email protected]

> Subject: Re: Problem building example application on windows-x64

>

> Hi Mark,

>

> On 12/27/2017 12:05 PM, Mark Rivers wrote:

> > I just did this again, but running makeBaseApp.pl with Windows rather

> > than Linux.  I get the same problem. It looks like the problem is that

> > testVersion.h is changing because the timestamp is incrementing by 1

> > second between the time it is created and checked?

>

> I agree; it seems to be a problem with the genVersionHeader.pl script

> that Michael added in 3.16.1 and the dependency rules. This is the

> relevant part of your build log:

>

> > perl -CSD H:/epics-devel/base-7.0.1/bin/windows-x64/genVersionHeader.pl

> > -t ../../.. -N testVERSION -V "" ../O.Common/testVersion.h

> >

> > Updating VCS header ../O.Common/testVersion.h

> >     testVERSION = "2017-12-27T11:39:33"

> >

> > perl -CSD H:/epics-devel/base-7.0.1/bin/windows-x64/mkmf.pl  -m

> > devtestVersion.d -I. -I../O.Common -I. -I. -I..

> > -I../../../include/compiler/msvc -I../../../include/os/WIN32

> > -I../../../include -IH:/epics-devel/base-7.0.1/include/compiler/msvc

> > -IH:/epics-devel/base-7.0.1/include/os/WIN32

> > -IH:/epics-devel/base-7.0.1/include        devtestVersion.obj

> > ../devtestVersion.c

> >

> > perl -CSD H:/epics-devel/base-7.0.1/bin/windows-x64/genVersionHeader.pl

> > -t ../../.. -N testVERSION -V "" ../O.Common/testVersion.h

> >

> > Updating VCS header ../O.Common/testVersion.h

> >     testVERSION = "2017-12-27T11:39:34"

> >

> > perl -CSD H:/epics-devel/base-7.0.1/bin/windows-x64/mkmf.pl  -m

> > devtestVersion.d -I. -I../O.Common -I. -I. -I..

> > -I../../../include/compiler/msvc -I../../../include/os/WIN32

> > -I../../../include -IH:/epics-devel/base-7.0.1/include/compiler/msvc

> > -IH:/epics-devel/base-7.0.1/include/os/WIN32

> > -IH:/epics-devel/base-7.0.1/include        devtestVersion.obj

> > ../devtestVersion.c

> >

> > perl -CSD H:/epics-devel/base-7.0.1/bin/windows-x64/genVersionHeader.pl

> > -t ../../.. -N testVERSION -V "" ../O.Common/testVersion.h

> >

> > Updating VCS header ../O.Common/testVersion.h

> >     testVERSION = "2017-12-27T11:39:35"

>

> whereas on Linux I get:

>

> > perl -CSD /home/phoebus/ANJ/epics/base/7.0/bin/linux-x86_64/genVersionHeader.pl

> >  -t ../../.. -N testVERSION -V "" ../O.Common/testVersion.h

> >

> > Updating VCS header ../O.Common/testVersion.h

> >     testVERSION = "2017-12-27T12:08:23-0600"

> >

> > /usr/bin/gcc  -D_GNU_SOURCE -D_DEFAULT_SOURCE         -

> DUSE_TYPED_RSET

> > -D_X86_64_  -DUNIX  -Dlinux     -O3 -g   -Wall      -mtune=generic     -m64

> > -Wpointer-arith -fvisibility=hidden -fPIC -I. -I../O.Common -I. -I. -I..

> > -I../../../include/compiler/gcc -I../../../include/os/Linux

> -I../../../include

> > -I/home/phoebus/ANJ/epics/base/7.0/include/compiler/gcc

> > -I/home/phoebus/ANJ/epics/base/7.0/include/os/Linux

> > -I/home/phoebus/ANJ/epics/base/7.0/include        -MM -MF devtestVersion.d

> > ../devtestVersion.c

> >

> > perl -CSD /home/phoebus/ANJ/epics/base/7.0/bin/linux-x86_64/genVersionHeader.pl

> >  -t ../../.. -N testVERSION -V "" ../O.Common/testVersion.h

> >

> > Keeping VCS header ../O.Common/testVersion.h

> >     testVERSION = "2017-12-27T12:08:23-0600"

>

> There seems to be a mismatch between the assumptions that script makes

> about file-system modification times and how GNUmake works on Windows.

> The old DOS FAT file-system had a time-stamp granularity of 2 seconds

> and that has resulted in some workarounds being added to GNUmake on

> Windows, e.g. see http://www.delorie.com/djgpp/v2faq/faq22_18.html or

> there may be a delay added at the end of the phase-1 run before GNUmake

> re-reads the Makefiles — that might explain what's happening here.

>

> Michael: How about we drop the seconds field completely from the build

> date/time-stamp? That should prevent this kind of problem from

> recurring. It would still trigger a re-creation of the header whenever

> there is a roll-over, but that should only happen once, not continuously

> like Mark is seeing.

>

> Mark: If you want to try out that fix, edit

> base-7.0/src/tools/genVersionHeader.pl and make this change:

>

> > diff --git a/src/tools/genVersionHeader.pl b/src/tools/genVersionHeader.pl

> > index 5851ea8..8e50fec 100644

> > --- a/src/tools/genVersionHeader.pl

> > +++ b/src/tools/genVersionHeader.pl

> > @@ -19,7 +19,7 @@ use POSIX qw(strftime);

> >  use strict;

> >

> >  # RFC 8601 date+time w/ zone (eg "2014-08-29T09:42:47-0700")

> > -my $tfmt = '%Y-%m-%dT%H:%M:%S';

> > +my $tfmt = '%Y-%m-%dT%H:%M';

> >  $tfmt .= '%z' unless $^O eq 'MSWin32'; # %z returns zone name on Windows

> >  my $now = strftime($tfmt, localtime);

> >

>

> - Andrew

>

> --

> Arguing for surveillance because you have nothing to hide is no

> different than making the claim, "I don't care about freedom of

> speech because I have nothing to say." -- Edward Snowdon