Re: New StreamDevice version

[Dirk Zimoch <dirk.zimoch@psi.ch>]

Hi Craig,

I plan to use a different solution for arbitrary whitespace now. I am 
thinking of something like "\_".

Regarding the stack overflow I have to dig through the source code.

Dirk

Craig.Haskins@csiro.au wrote:
> Hi Dirk,
>
> Thanks for that, I think the ability to consume arbitrary amounts of whitespace is useful as it does make the protocol files easier.  At least for me, the backwards compatibly for me isn't a big deal as this is a new device I'm writing support for.  btw, I like the new TIME feature, it neatly solves a problem I had with trying to set the time and date in my device.  
>
> I've ran into another problem with the latest snapshots though (both 20101203 and 20101129 but not in 20100615).  I'm seeing a crash in StreamCore.cc.  It doesn't seem to happen with a device emulator I have but does wit the real device which responds a bit slower (it's an RS-232 over Ethernet device) so it might be timing related.  It looks like StreamDevice is getting stuck in a loop as the call stack is over 300 calls deep when it crashes.  It's going between evalIn() and readCallback().
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000100686e08
> [Switching to process 6213]
> 0x00000001000a0818 in StreamCore::readCallback (this=0x102008800, status=StreamIoTimeout, input=0x0, size=0) at ../StreamCore.cc:903
> 903	    const void* input, long size)
> (gdb) b
> Breakpoint 1 at 0x1000a0818: file ../StreamCore.cc, line 903.
> (gdb) bt 
> #0  0x00000001000a0818 in StreamCore::readCallback (this=0x102008800, status=StreamIoTimeout, input=0x0, size=0) at ../StreamCore.cc:903
> #1  0x000000010009e823 in StreamCore::evalIn (this=0x102008800) at ../StreamCore.cc:874
> #2  0x00000001000a13e3 in StreamCore::readCallback (this=0x102008800, status=StreamIoTimeout, input=<value temporarily unavailable, due to optimizations>, size=0) at ../StreamCore.cc:1070
> #3  0x000000010009e823 in StreamCore::evalIn (this=0x102008800) at ../StreamCore.cc:874
> #4  0x00000001000a13e3 in StreamCore::readCallback (this=0x102008800, status=StreamIoTimeout, input=<value temporarily unavailable, due to optimizations>, size=0) at ../StreamCore.cc:1070
> ..
> ..
> #311 0x000000010009e823 in StreamCore::evalIn (this=0x102008800) at ../StreamCore.cc:874
> #312 0x00000001000a13e3 in StreamCore::readCallback (this=0x102008800, status=StreamIoTimeout, input=<value temporarily unavailable, due to optimizations>, size=0) at ../StreamCore.cc:1070
> #313 0x0000000100089c5f in StreamBusInterface::readCallback () at /Users/has09e/src/askapsoft/3rdParty/EPICS/3.14.11/support/streamDevice/streamDevice-2-5/StreamDevice-2-5/src/StreamBusInterface.h:933
> #314 0x0000000100089c5f in AsynDriverInterface::readHandler (this=0x1010039b0) at ../AsynDriverInterface.cc:933
> #315 0x0000000100089eb8 in handleRequest (pasynUser=<value temporarily unavailable, due to optimizations>) at ../AsynDriverInterface.cc:1356
> #316 0x000000010000dd0d in portThread (pport=0x100465f10) at ../../asyn/asynDriver/asynManager.c:828
> #317 0x000000010028bbe2 in start_routine (arg=<value temporarily unavailable, due to optimizations>) at ../../../src/libCom/osi/os/posix/osdThread.c:282
> #318 0x00007fff804cb536 in _pthread_start ()
> #319 0x00007fff804cb3e9 in thread_start ()
>
> The protocol looks like this
>
> one command to send out the poll
>
> get_flashNearN {
>     out "A";
>     in "NEAR: N %f     NE %*f     E %*f     SE %*f     S %*f     SW %*f     W %*f     NW %*f    ";
> }
>
> and 18 commands that are set as INTR/IO scan in the records
>
> get_flashDistNW {
>     in "DIST: N %*f     NE %*f     E %*f    SE %*f     S %*f     SW %*f     W %*f     NW %f    ";
> }
>
> get_flashCloud {
>     in "OVHD %*f     CLOUD %f     TOTAL %*f     P %*2XH %*f C";
> }
>
> I've only tested this on the mac so far.  If there is any debug trace I can get to help find the issue please let me know.
>
> Regards
>
> Craig
>
> On 03/12/2010, at 9:59 PM, Dirk Zimoch wrote:
>
> > Hello Craig,
> >
> > Thanks for testing it on Mac.
> >
> > The effect you found is indeed an incompatibility. I think I better 
> > remove it again and look for something better. I was trying to be more 
> > compatible with the sscanf format strings, where a space consumes 
> > arbitrary amounts of whitespace (see: man sscanf). Thus in your case it 
> > is not the last %s but the spaces after the %s that consume the \r\n. I 
> > think I better remove that feature again to stay backward compatible. 
> > Maybe I better go for a special escape sequence for "arbitrary amount of 
> > white space".
> >
> > Dirk
> >
> > Craig.Haskins@csiro.au wrote:
> > > Hi Dirk,
> > >
> > > Thanks for the new release.  I can confirm it builds OK on Snow Leopard 10.6.5.  I've run into a difference with the previous snapshot though.  I have a protocol as follows
> > >
> > > InTerminator = "> ";
> > > OutTerminator = CR LF;
> > > ExtraInput = Ignore;
> > >
> > > get_airTemp {
> > >    out "R1";
> > >    in "R1\r\n%*s   ,%*s   ,%*s   ,%*s   ,%*s   ,%*s   ,%*s   ,%*s   ,%*s   ,%*s   ,%*s   ,%*s   ,%*s   ,%*s   ,%*s   \r\n%*f,%*f,%*f,%f,%*f,%*f,%*f,%*f,%*f,%*f,%*f,%*f,%*f,%*f,%*f";
> > > }
> > >
> > > to handle the follow command & 3 line response from my device
> > >
> > > > R1
> > > R1
> > > WS=   ,WD=   ,RH=   ,AT=   ,RG=   ,SR=   ,BP=   ,S1=   ,S2=   ,BV=   ,LC=   ,SV=   ,CC=   ,9R=   ,Ev=
> > > +000006.02,+000106.95,+000051.97,+000027.21,+000006.92,+000010.50,+000902.35,+000019.26,+000018.63,+000012.37,+000035.12,+000012.47,+000249.95,+000009.65,+000004.03
> > > km/h   ,Degrees,%      ,Deg C  ,mm     ,W/m^2  ,hPa    ,Deg C  ,Deg C  ,V      ,mA     ,V      ,mA     ,mm     ,mm
> > >
> > > The reason for using "> " for the input terminator is to handle a command prompt that the device sends without a CR LF.  I then treat the 3 line response as a single line with "\r\n" in the format string.  This worked quite well for the 20100615 snapshot but with the latest, I find that the last %*s before the \r\n also consumes the \r\n.  So for the new snapshot I need to remove the 2nd "\r\n" in the format string.  Not sure if this change was intentional or not. Other than that, works fine on Mac.
> > >
> > > Regards
> > >
> > > Craig
> > >
> > > -------------------------------------------------------
> > > Craig Haskins
> > > Software Engineer
> > > Australia Telescope National Facility
> > > CSIRO Astronomy and Space Science
> > > P.O.Box 76, Epping NSW 1710, Australia
> > > Phone: +61 2 9372 4309
> > > email: Craig.Haskins@csiro.au
>
> -------------------------------------------------------
> Craig Haskins
> Software Engineer
> Australia Telescope National Facility
> CSIRO Astronomy and Space Science
> P.O.Box 76, Epping NSW 1710, Australia
> Phone: +61 2 9372 4309
> email: Craig.Haskins@csiro.au