Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: Scalcout data corruption on darwin-x86 with x86_64 arch class
From: Bruce Hill <bhill@slac.stanford.edu>
To: "J. Lewis Muir" <jlmuir@anl.gov>
Cc: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Fri, 26 Aug 2011 22:21:26 -0700
Hi Lewis,
I think the root problem is that %d (and other conversion types) expect a
pointer to an int, not a long.    Initializing the l and ul variables just gives you
consistency, not correct behavior.  Also, if you want to use "%ld" to allow
for values over 32 bits, you'd need to extend the code to check for the 'l'
modifier, similar to what it's doing for the 'h' modifier.

               case 'd': case 'i':
                    if (s[-1] == 'h') {
                        sscanf(ps->s, ps1->s, &h);
                        ps->d = (double)h;
                    } else if (s[-1] == 'l') {
                        sscanf(ps->s, ps1->s, &l);
                        ps->d = (double)l;
                    } else {
                        sscanf(ps->s, ps1->s, &i);
                        ps->d = (double)i;
                    }


There are other type modifiers besides 'h' and 'l', but the code isn't checking
for them so use of type modifiers such as "ll", "L", "hh", etc will also cause
problems.

Regards,
- Bruce

On 08/18/2011 02:41 PM, J. Lewis Muir wrote:
On 8/18/11 3:26 PM, Tim Mooney wrote:
  
Awesome!  I haven't reproduced the symptom on my x86_64 system, but
anyway it's clear that the code needs this fix.  I'll look for other
similar problems.
Thanks to you both.
Tim
    
Hi, Tim.

I think I've found another problem: using SSCANF to parse '-1'
with a '%d' format does not result in a value of -1.  Attached
is scalcout-corrupt2.db which demonstrates this.  After loading
it into an IOC, I did the following from a Bash shell:

  $ caget ioc23:Temperature.{VAL,SVAL}
  ioc23:Temperature.VAL          4.29497e+09
  ioc23:Temperature.SVAL         4294967295.000

The value should be -1.

Like the previous problem, it works fine with the i386
architecture class.

And if I change the '%d' to '%ld', it works fine for the x86_64
architecture class.

Thanks,

Lewis
  

-- 
Bruce Hill
Member Technical Staff
SLAC National Accelerator Lab
2575 Sand Hill Road M/S 10
Menlo Park, CA  94025

References:
Re: Scalcout data corruption on darwin-x86 with x86_64 arch class Tim Mooney
Re: Scalcout data corruption on darwin-x86 with x86_64 arch class J. Lewis Muir

Navigate by Date:
Prev: Re: 'open' epics backup? Pete Jemian
Next: CSS Archive Search URL Julio Calvo
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: Re: Scalcout data corruption on darwin-x86 with x86_64 arch class J. Lewis Muir
Next: Announce: sequencer release 2.1.1 Benjamin Franksen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·