Re: Strange problem with EPICS areaDetector

[Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov>]

On 6/19/24 23:52, Jörn Dreyer wrote:
> Hi Michael,
>
> yes, you are right that the level of optimization plays a role wether the check triggers a fault or not.
> At leas thats what the documentation of the _FORTIFY_SOURCE macro says.
I have updated PR #517 with a prospective fix:

https://urldefense.us/v3/__https://github.com/epics-base/epics-base/pull/517__;!!G_uCfscf7eWS!eKp-ZYPRg0XnAzxUmvEfWpVrdgBJ5A3DK-rPLPKM7M1LSKwR6nnJKssE2ofgaBaly2EwJMN9sZUFAO65zaXRU7qX4Q$ 

> Jörn
>
> Am Donnerstag, 20. Juni 2024, 07:28:29 MESZ schrieb Michael Davidsaver via Tech-talk:
> > On 6/19/24 21:26, Michael Davidsaver wrote:
> > > I see something like the following.  All of the 'f's mean that GCC
> > > is unable to track the sizes of the objects involved.  I also don't
> > > see a fault.
> > >
> > > > X test.LINR ptemp=ffffffffffffffff,ffffffffffffffff papChoice=ffffffffffffffff,ffffffffffffffff i=0
> > I spoke too soon.  I can reproduce, but not with a -debug build.
> > So I guess '-O2' vs '-O3' plays some role?
> >
> > > X test.LINR ptemp=ffffffffffffffff,28 papChoice=ffffffffffffffff,ffffffffffffffff i=0
> > > X test.LINR ptemp=ffffffffffffffff,0 papChoice=ffffffffffffffff,ffffffffffffffff i=1
> > > *** buffer overflow detected ***: terminated
> > The inferred size of 'ptemp' is 28 bytes, which I can only assume comes from
> > this line.
> >
> > > ptemp = &(pdbr_enumStrs->strs[0][0]);
> > I don't understand why 28 and not 1, 30, or 30*40 ?
> >
> > The first iteration steps past this.
> >
> > > ptemp += sizeof(pdbr_enumStrs->strs[0]);
> > This is certainly an odd way to iterate an array...