Re: base-3.16.1 bug

[Michael Davidsaver <mdavidsaver@gmail.com>]

On 09/06/2017 06:40 AM, Ralph Lange wrote:
> Hi Andrew,
> 
> I'm running into this right now, because it is failing my tests (that
> try to write to a bo record).
> 
> Why is none of our tests catching this?

Because we need more test coverage?  (to state the blindingly obvious)

@Andrew Will you be adding a test to trigger this regression before
fixing it?  src/std/rec/test/regressTest.c would be a easy place.

> (dbPutLinkTest is named like it should.)

dbPutLinkTest is presently testing dbPutField() to link fields.  Link
string parsing.

> I would say the dummy method returning OK is the way to go. Other link
> types might return errors that are worth reporting, and it is certainly
> a property of the CONSTANT link that a put() operation is never
> producing an error.

I agree with this.


Another inconsistency.  CA put w/ callback is losing the error.  I see
that dbNotify ignores the result of dbProcess().  It would be nice if it
didn't...


> $ caput -c box 1
> Old : box                            0
> New : box                            1
> $ caput  box 1
> Old : box                            1
> CA.Client.Exception...............................................
>     Warning: "Channel write request failed"
>     Context: "op=1, channel=box, type=DBR_STRING, count=1, ctx="box""
> New : box                            1
>     Source File: ../oldChannelNotify.cpp line 160
>     Current Time: Wed Sep 06 2017 11:42:55.060212280
> ..................................................................
> $ cat test.db
> record(ao, "box") {}

I also noticed that dbNotify doesn't propagate some errors in it's
putCallback for link fields.



> Cheers,
> ~Ralph
> 
> 
> 
> On Thu, Aug 31, 2017 at 11:35 PM, Andrew Johnson <anj@aps.anl.gov
> <mailto:anj@aps.anl.gov>> wrote:
> 
>     [...]
>     The problem is related to the new Link Support code: The OUT links in
>     both ao records are unset so are CONSTANT links, and the ao Soft Device
>     support returns the status value it gets from calling dbPutLink() as the
>     result of its write_ao() method, but for the CONSTANT link type there is
>     no lset::putValue() method, so the return value from dbPutLink() is
>     S_db_noLSET, which now gets returned all the way back through the
>     rset::process() method up to the routine dbChannel_put() so RSRV sees an
>     error from the put which it passes back to the CA client.
> 
>     The same problem will probably occur with bo, stringout and lso records
>     because the soft device support for those record types also pass the
>     return value from dbPutLink() back to the record type. Other device
>     supports always return 0 independent of what dbPutLink() returns so
>     won't generate the error.
> 
>     Ralph, Michael:
> 
>     Where do you think is the correct place to squash this error? Should I
>     add a dummy lset::putValue() method to the dbConstLink type (that just
>     returns OK), or change the soft device supports to discard the return
>     value from dbPutLink()?
> 
>     - 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
> 
>

Attachment: signature.asc
Description: OpenPGP digital signature