Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Sat, 28 Jul 2012 03:56:03 +0000

If you are getting a segmentation violation then you can get a lot more information on what happened.

Enable core dumps:

limit core 10000000

Now when it seg faults you will get a core dump.

Run gdb on the core file:

gdb ./../bin/linux-x86_64/DrvTest core.xxxx

When gdb starts type the command

bt

That will give you a stack trace, and we will know where it crashed.

Mark

________________________________________
From: [email protected] [[email protected]] on behalf of [email protected] [[email protected]]
Sent: Friday, July 27, 2012 9:22 PM
To: Eric Norum
Cc: [email protected]
Subject: Re: Waveform read problems

Hey Eric,

Thanks for looking at this. Here is my startup script:

#!../../bin/linux-x86_64/DrvTest
## You may have to change DrvTest to something else
## everywhere it appears in this file
< envPaths
epicsEnvSet("ARCH","linux-x86_64")
epicsEnvSet("IOC","iocDrvTest")
epicsEnvSet("TOP","/home/admx/admxepics/iocs/DrvTest")
epicsEnvSet("ASYN","/home/admx/epics/asyn4-18")
epicsEnvSet("AG8657B","/home/admx/admxepics/devices/ag8657B")
epicsEnvSet("AG8648B","/home/admx/admxepics/devices/ag8648B")
epicsEnvSet("AGE5071C","/home/admx/admxepics/devices/agE5071C")
epicsEnvSet("PROLOGIXGPIB","/home/admx/admxepics/devices/PrologixGPIB")
epicsEnvSet("EPICS_BASE","/home/admx/epics/base-3.14.12.2")
epicsEnvSet(EPICS_CA_MAX_ARRAY_BYTES, 100000)
cd /home/admx/admxepics/iocs/DrvTest
## Register all support components
dbLoadDatabase "dbd/DrvTest.dbd"
DrvTest_registerRecordDeviceDriver pdbbase
##Load Prologix Driver
##prologixGPIBConfigure("L0", "10.95.101.60:1234",0,1)
##asynOctetSetInputEos("L0", -1, "\n")
##asynSetTraceIOMask("L0_TCP", -1, 0x2)
##asynSetTraceMask("L0_TCP", -1, 0x9)
##asynSetTraceIOMask("L0", 5, 0x2)
##asynAutoConnect "L0" -1 1
##epicsThreadSleep 2
prologixGPIBConfigure("L0", "10.95.101.60:1234")
drvAsynIPPortConfigure("L1","10.95.101.61:5025",0,0,0)
asynOctetSetInputEos("L1",0,"\n")
asynOctetSetOutputEos("L1",0,"\n")
asynSetTraceIOMask("L1", -1, 0x2)
asynSetTraceMask("L1", -1, 0x9)
asynSetTraceIOTruncateSize("L1", -1, 16384)
## Load record instances
cd /home/admx/admxepics/devices/ag8648B
dbLoadRecords("db/devAG8648B.db","SIGGEN=AG8648B,L=0,A=19")
dbLoadRecords("db/devAG8648B.db","SIGGEN=AG8648D,L=0,A=10")
cd /home/admx/admxepics/devices/agE5071C
dbLoadRecords("db/devAGE5071C.db","NETWA=AGE5071C,L=1,A=0")
cd /home/admx/admxepics/iocs/DrvTest/iocBoot/iocDrvTest

Actually, I think I figured out some of what was confusing me earlier. By Setting the asynSetTraceIOTruncateSize sufficiently large I can at least see the entirety of what asyn is reading. When processing a wf record the behavior is, read 2048 characters at a time until message ends then Segmentation violation. When processing asynOctetWriteRead the behavior is read first 2048 characters then stop. If you can't guess what could cause the segfault (see first message in this thread) then I'll try updating to a stream device driver. Thanks again for all your help.

Cheers,

Andrew

epics> asynOctetConnect("NW","L1")
epics> asynOctetWriteRead("NW",":SENS1:FREQ:DATA?")
2012/07/27 19:11:07.620 10.95.101.61:5025 write 18
:SENS1:FREQ:DATA?\n
2012/07/27 19:11:07.622 10.95.101.61:5025 read 2048
+4.50000000000E+008,+4.55250000000E+008,+4.60500000000E+008,+4.65750000000E+008,+4.71000000000E+008,+4.76250000000E+008,+4.81500000000E+008,+4.86750000000E+008,+4.92000000000E+008,+4.97250000000E+008,+5.02500000000E+008,+5.07750000000E+008,+5.13000000000E+008,+5.18250000000E+008,+5.23500000000E+008,+5.28750000000E+008,+5.34000000000E+008,+5.39250000000E+008,+5.44500000000E+008,+5.49750000000E+008,+5.55000000000E+008,+5.60250000000E+008,+5.65500000000E+008,+5.70750000000E+008,+5.76000000000E+008,+5.81250000000E+008,+5.86500000000E+008,+5.91750000000E+008,+5.97000000000E+008,+6.02250000000E+008,+6.07500000000E+008,+6.12750000000E+008,+6.18000000000E+008,+6.23250000000E+008,+6.28500000000E+008,+6.33750000000E+008,+6.39000000000E+008,+6.44250000000E+008,+6.49500000000E+008,+6.54750000000E+008,+6.60000000000E+008,+6.65250000000E+008,+6.70500000000E+008,+6.75750000000E+008,+6.81000000000E+008,+6.86250000000E+008,+6.91500000000E+008,+6.96750000000E+008,+7.02000000000E+008,+7.072500!
 00000E+008,+7.12500000000E+008,+7.17750000000E+008,+7.23000000000E+008,+7.28250000000E+008,+7.33500000000E+008,+7.38750000000E+008,+7.44000000000E+008,+7.49250000000E+008,+7.54500000000E+008,+7.59750000000E+008,+7.65000000000E+008,+7.70250000000E+008,+7.75500000000E+008,+7.80750000000E+008,+7.86000000000E+008,+7.91250000000E+008,+7.96500000000E+008,+8.01750000000E+008,+8.07000000000E+008,+8.12250000000E+008,+8.17500000000E+008,+8.22750000000E+008,+8.28000000000E+008,+8.33250000000E+008,+8.38500000000E+008,+8.43750000000E+008,+8.49000000000E+008,+8.54250000000E+008,+8.59500000000E+008,+8.64750000000E+008,+8.70000000000E+008,+8.75250000000E+008,+8.80500000000E+008,+8.85750000000E+008,+8.91000000000E+008,+8.96250000000E+008,+9.01500000000E+008,+9.06750000000E+008,+9.12000000000E+008,+9.17250000000E+008,+9.22500000000E+008,+9.27750000000E+008,+9.33000000000E+008,+9.38250000000E+008,+9.43500000000E+008,+9.48750000000E+008,+9.54000000000E+008,+9.59250000000E+008,+9.64500000000E+0!
 08,+9.69750000000E+008,+9.75000000000E+008,+9.80250000000E+008!
 ,+9.85500
eomReason 0x1
+4.50000000000E+008,+4.55250000000E+008,+4.60500000000E+008,+4.65750000000E+008,+4.71000000000E+008,+4.76250000000E+008,+4.81500000000E+008,+4.86750000000E+008,
epics>

On Fri, 27 Jul 2012, Eric Norum wrote:

> An alternative question is why the interposeEOS layer is present.
> What xxxxConfigure command are you using to create the asyn port?
> What other asynXXXXX commands are in your startup script?
> Please send the entire startup script for us to have a look at.
>
> On Jul 27, 2012, at 6:10 PM, Andrew Wagner wrote:
>
>> Ah! Now the question why doesn't it seem to do this. In the example below I read 2048 characters then get an eomReason 0x1 then nothing. I don't think you need my network analyzer to debug this, just something that sends a long string of numbers.
>>
>> Andrew
>>
>> On Jul 27, 2012, at 5:52 PM, Eric Norum wrote:
>>
>>> Yes, there is a 2048-character buffer -- it's in the interposeEOS layer.  That's why the read is returning with EOM=COUNT.
>>> But the interposeEOS layer should then just issue another read until the incoming message really does end.
>>>
>>> On Jul 27, 2012, at 5:45 PM, Mark Rivers wrote:
>>>
>>>> asyn reads as much data as the device sends.  There is no buffer size limit of 2048 anywhere in asyn.  I suspect your device is sending data in 2048 character chunks, and you need to do another "read" operation to get the next chunk of data.  Is this GPIB, Ethernet, or serial?
>>>>
>>>> Mark
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: [email protected] [mailto:[email protected]]
>>>> Sent: Friday, July 27, 2012 7:24 PM
>>>> To: Mark Rivers
>>>> Cc: [email protected]
>>>> Subject: RE: Waveform read problems
>>>>
>>>> Thanks for the advice. I'll definitely look into StreamDevice, it sounds really nice. Unfortunately, I've done a little more debugging and I'm pretty sure the problem is in asyn, not my driver. For instance when I try to connect directly with asynOctet, I get:
>>>>
>>>> epics> asynOctetConnect("NW","L1")
>>>> epics> asynOctetWriteRead("NW","*IDN?")
>>>> 2012/07/27 16:43:04.491 10.95.101.61:5025 write 6
>>>> *IDN?\n
>>>> 2012/07/27 16:43:04.492 10.95.101.61:5025 read 47
>>>> Agilent Technologies,E5071C,MY46213997,A.10.06\n
>>>> eomReason 0x2
>>>> Agilent Technologies,E5071C,MY46213997,A.10.06
>>>> epics> asynOctetWriteRead("NW",":SENS1:FREQ:DATA?")
>>>> 2012/07/27 16:43:17.503 10.95.101.61:5025 write 18
>>>> :SENS1:FREQ:DATA?\n
>>>> 2012/07/27 16:43:17.505 10.95.101.61:5025 read 2048
>>>> +5.00000000000E+008,+5.05000000000E+008,+5.10000000000E+008,+5.15000000000E+008,+5.20000000000E+008,+5.25000000000E+008,
>>>> eomReason 0x1
>>>> +5.00000000000E+008,+5.05000000000E+008,+5.10000000000E+008,+5.15000000000E+008,+5.20000000000E+008,+5.25000000000E+008,+5.30000000000E+008,+5.35000000000E+008,
>>>> epics>
>>>>
>>>> No Segfault this time however, the entire data stream is truncated after 2048 characters. I'm getting the impression there is something fundamental I'm not understanding about how asyn manages data. I looked over Eric's Stream device tutorial and could find no reason why converting my driver support to stream device would solve this problem since asyn is still handling the communication. My problem remains that I don't understand how to get asyn to read more than 2048 characters. The solution must be very simple otherwise asyn could never have been used with a wf record.
>>>>
>>>> Cheers,
>>>>
>>>> Andrew
>>>>
>>>> On Fri, 27 Jul 2012, Mark Rivers wrote:
>>>>
>>>>> You might want to consider using streamDevice rather than the asynGpib software.  asynGpib is rather obsolete; steamDevice is much nicer.  You don't need to write any C code if you use streamDevice.
>>>>>
>>>>> Eric Norum has recently written a new version of his "HowToDoSerial" tutorial, explaining how to use asyn with streamDevice.  It will be in the next release of asyn, but meanwhile you can find it here:
>>>>>
>>>>> http://cars.uchicago.edu/software/epics/HowToDoSerial_StreamDevice.html
>>>>>
>>>>> Cheers,
>>>>> Mark
>>>>>
>>>>>
>>>>> ________________________________________
>>>>> From: [email protected] [[email protected]] on behalf of [email protected] [[email protected]]
>>>>> Sent: Friday, July 27, 2012 4:53 PM
>>>>> To: [email protected]
>>>>> Subject: Waveform read problems
>>>>>
>>>>> Hey Everyone,
>>>>>
>>>>> I'm using Asyn to create a driver for the Agilent E5071C Network analyzer and am trying to create a working waveform record to readout the analyzer traces. The output of the analyzer is a list of ASCII values separated by commas. For instance, :SENS1:FREQ:DATA? returns the frequency values where the power was measured in Hz. The output is:+5.00000000000E+008,+5.05000000000E+008,+5.10000000000E+008,+5.15000000000E+008,+5.20000000000E+008,+5.25000000000E+008, ... I'm able to communicate with the analyzer, however I create a Segmentation violation when processing waveform records to store this array.
>>>>>
>>>>>
>>>>> epics> dbtr AGE5071C:FREQ
>>>>> ACKS: NO_ALARM      ACKT: YES           APST: Always        ASG:
>>>>> BKPT: 00            BUSY: 0             DESC: Frequency Series Hz
>>>>> DISA: 0             DISP: 0             DISS: NO_ALARM      DISV: 1
>>>>> 2012/07/27 14:12:12.823 DTYP: AGE5071C      EGU: Hz             EVNT: 0             FLNK:CONSTANT 0
>>>>> 10.95.101.61:5025 write 18
>>>>> :SEFTVL: DOUBLE        HASH: 0             HOPR: 0
>>>>> NS1INP:GPIB_IO #L1 A0 @9                   LCNT: 0             LOPR: 0
>>>>> :FREMPST: Always        NAME: AGE5071C:FREQ NELM: 10000         NORD: 0
>>>>> Q:DANSEV: NO_ALARM      NSTA: NO_ALARM      PACT: 1             PHAS: 0
>>>>> TA?PINI: NO            PREC: 0             PRIO: LOW           PROC: 0
>>>>> \n
>>>>> PUTF: 0             RARM: 0             RPRO: 0             SCAN: Passive
>>>>> SDIS:CONSTANT       SEVR: INVALID       SIML:CONSTANT       SIMM: NO
>>>>> SIMS: NO_ALARM      SIOL:CONSTANT       STAT: UDF           TIME: <undefined>
>>>>> TPRO: 0             TSE: 0              TSEL:CONSTANT       UDF: 1
>>>>> VAL: (nil)
>>>>> epics> 2012/07/27 14:12:12.825 10.95.101.61:5025 read 2048
>>>>> +5.00000000000E+008,+5.05000000000E+008,+5.10000000000E+008,+5.15000000000E+008,+5.20000000000E+008,+5.25000000000E+008,
>>>>> 2012/07/27 14:12:12.825 10.95.101.61:5025 read 1972
>>>>> 000000E+009,+1.01500000000E+009,+1.02000000000E+009,+1.02500000000E+009,+1.03000000000E+009,+1.03500000000E+009,+1.04000
>>>>> Segmentation fault
>>>>>
>>>>>
>>>>> I'm defining the gpibCMD as:
>>>>>
>>>>> {&DSET_WF, GPIBREAD, IB_Q_HIGH, ":SENS1:FREQ:DATA?", NULL, 0, 32000, readWF, 0, 0, NULL, NULL, NULL},
>>>>>
>>>>> and the custom convert routine I'm using is:
>>>>>
>>>>> // WF read routine for AGE5071C
>>>>> static int readWF(struct gpibDpvt *pdpvt,int P1, int P2, char**P3) {
>>>>>
>>>>> printf("%s","TEST****************************************");
>>>>>
>>>>> struct waveformRecord *pwf=(struct waveformRecord *)pdpvt->precord;
>>>>> asynUser *pasynUser = pdpvt->pasynUser;
>>>>>
>>>>> double* value = (double *)pwf->bptr;
>>>>> double data;
>>>>> int n;
>>>>> char* buffer = "\0";
>>>>>
>>>>> pwf->nord=0;
>>>>> strcpy(buffer,pdpvt->msg);
>>>>>
>>>>> while ((pwf->nord < pwf->nelm) && sscanf(buffer,"%lE,%n",&data,&n)==1) {
>>>>>
>>>>> memcpy(value+pwf->nord,&data,sizeof(double));
>>>>> pwf->nord++;
>>>>> buffer+=n;
>>>>>
>>>>> asynPrint(pasynUser,ASYN_TRACE_FLOW,"(NORD,VAL) : (%i,%E)\n",pwf->nord,data);
>>>>>
>>>>> }
>>>>>
>>>>> if (pwf->nord == 0) return -1;
>>>>>
>>>>> return 0;
>>>>>
>>>>> }
>>>>>
>>>>> Since none of my error messages are printed I conclude the pdpvt->msg array is being overfilled somehow before my convert routine is even processed. I'm really not sure how to debug this since everything that I've written seems to work fine. The debug messages reveal no problems until the Segmentation violation occurs. I also don't understand why the reads can only handle a maximum of 2048 characters at a time. If anyone has experience writing device support for a waveform record your advice would be very helpful. Thanks.
>>>>>
>>>>> Andrew
>>>>
>>>>
>>>
>>> --
>>> Eric Norum
>>> [email protected]
>>>
>>>
>>>
>>>
>>
>>
>
> --
> Eric Norum
> [email protected]
>
>
>
>
>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System