EPICS Home

Experimental Physics and Industrial Control System


 
2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: db_create_event_log
From: Andrew Johnson <[email protected]>
To: "Hill, Jeff" <[email protected]>
Cc: "[email protected]" <[email protected]>
Date: Mon, 4 Nov 2013 13:37:05 -0600
Hi Jeff,

I expect Ralph to take a look at this as soon as he gets a chance, since he developed these changes. Putting your observations and comments into a Launchpad bug report would indeed be very helpful, thanks.

- Andrew

On 11/04/2013 01:23 PM, Hill, Jeff wrote:
Maybe I see another R3.15 bug; when in an out-of-memory situation the code in the filter arr.c at line 122 allocates pdst but does not check the return from freeListCalloc. If it is nill then u.r.field will also be nill. It seems that further down in arr.c at line 127 dbExtractArrayFromBuf will memcpy to a nill pointer destination if u.r.field is nill?

                 void *pdst = freeListCalloc(my->arrayFreeList);

                 pfl->u.r.dtor = freeArray;
                 pfl->u.r.pvt = my->arrayFreeList;
                 offset = (offset + start) % chan->addr.no_elements;
                 dbExtractArrayFromRec(&chan->addr, pdst, nTarget, nSource, offset, my->incr);
                 pfl->u.r.field = pdst;

It seems that similar issues exist further down in arr.c at line 143 where dbExtractArrayFromBuf will memcpy to a nill pointer destination when u.r.field is initialized nill, in an out-of-memory situation?

             pdst = freeListCalloc(my->arrayFreeList);
             offset = start;
             dbExtractArrayFromBuf(psrc, pdst, pfl->field_size, pfl->field_type, nTarget, nSource, offset, my->incr);

Looking in the source it appears that there are several additional defects following this pattern.

Should I submit a bug report?

Jeff
-----Original Message-----
From: [email protected] [mailto:core-talk-
[email protected]] On Behalf Of Hill, Jeff
Sent: Monday, November 04, 2013 11:06 AM
To: [email protected]
Subject: db_create_event_log

Hello All,

I was having a closer look at the recent changes in R3.15; my perception is
that behavior has changed and that in an out-of-memory situation R3.15 is
currently discarding the update for the event queue instead of the original
behavior which was replacing the last entry on the queue for the subscription
that was being posted, in an out-of-memory situation.

Should I submit a defect report; or perhaps this was this an intentional
behavior change in R3.15?

Ref: in the code below if db_create_event_log returns null due to out-of-
memory condition then db_post_events is a noop.

int db_post_events(
void            *pRecord,
void            *pField,
unsigned int    caEventMask
)
{
     struct dbCommon   * const prec = (struct dbCommon *) pRecord;
     struct evSubscrip *pevent;

     if (prec->mlis.count == 0) return DB_EVENT_OK;       /* no monitors set */

     LOCKREC (prec);

     for (pevent = (struct evSubscrip *) prec->mlis.node.next;
         pevent; pevent = (struct evSubscrip *) pevent->node.next){

         /*
          * Only send event msg if they are waiting on the field which
          * changed or pval==NULL and waiting on alarms and alarms changed
          */
         if ( (dbChannelField(pevent->chan) == (void *)pField || pField==NULL) &&
             (caEventMask & pevent->select)) {
             db_field_log *pLog = db_create_event_log(pevent);
             pLog = dbChannelRunPreChain(pevent->chan, pLog);
             if (pLog) db_queue_event_log(pevent, pLog);
         }
     }

     UNLOCKREC (prec);
     return DB_EVENT_OK;

}




--
Advertising may be described as the science of arresting the human
intelligence long enough to get money from it. -- Stephen Leacock

References:
db_create_event_log Hill, Jeff
RE: db_create_event_log Hill, Jeff

Navigate by Date:
Prev: RE: db_create_event_log Hill, Jeff
Next: Re: posting DBE_PROPERTY Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: db_create_event_log Hill, Jeff
Next: posting DBE_PROPERTY Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024