Hi Ralph,
after some more thinking and investigation, I found a more propper fix for the problem. If one adds the following two lines to
base/configure/os/CONFIG_SITE.linux-x86_64.UnixCommon
CFLAGS += -D_FORTIFY_SOURCE=2
CXXFLAGS += -D_FORTIFY_SOURCE=2
the code gets compiled with the old setting of _FORTIFY_SOURCE. Thats only a temporary fix of course. Clearly the code should be fixed for this errors.
Regards
Jörn
Am Mittwoch, 19. Juni 2024, 10:58:20 MESZ schrieb Jörn Dreyer via Tech-talk:
> Hi Ralph,
>
> at least the IOC can loads the database without bailing out directly, but still there seems to be another problem:
>
> #9 0x00007ffff7d8ab4e in strncpy (__len=40, __src=<optimized out>, __dest=<optimized out>)
> at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:95
> #10 get_enum_strs
> (options=0x7fffae5ff2c0, prset=0x7ffff7e48580 <aiRSET>, ppbuffer=<synthetischer Zeiger>, paddr=0x7fff8c06b960)
> at ../db/dbAccess.c:192
> #11 getOptions (pflin=0x0, options=0x7fffae5ff2c0, poriginal=<synthetischer Zeiger>, paddr=0x7fff8c06b960)
> at ../db/dbAccess.c:415
> #12 dbGet
> (paddr=paddr@entry=0x7fff8c06b960, dbrType=dbrType@entry=11, pbuffer=pbuffer@entry=0x7fffae5ff310, options=options@entry=0x7fffae5ff2c0, nRequest=nRequest@entry=0x7fffae5ff2c8, pflin=pflin@entry=0x0) at ../db/dbAccess.c:917
> #13 0x00007ffff7d8d820 in dbChannelGet
> (chan=chan@entry=0x7fff8c06b958, type=type@entry=11, pbuffer=pbuffer@entry=0x7fffae5ff310, options=options@entry=0x7fffae5ff2c0, nRequest=nRequest@entry=0x7fffae5ff2c8, pfl=pfl@entry=0x0) at ../db/dbChannel.c:630
> #14 0x00007ffff7da6408 in dbChannel_get_count
> (chan=chan@entry=0x7fff8c06b958, buffer_type=<optimized out>, pbuffer=0x7fff8403d3e0, nRequest=nRequest@entry=0x7fffae5ff838, pfl=pfl@entry=0x0) at ../db/db_access.c:644
> #15 0x00007ffff7dcef34 in read_reply
> (pArg=pArg@entry=0x7fffae5ff890, dbch=0x7fff8c06b958, eventsRemaining=eventsRemaining@entry=1, pfl=pfl@entry=0x0)
> at ../rsrv/camessage.c:548
>
> This happens when accessing a pv that is on the ADBase screen. I don't know which one it could be.
>
> Regards,
>
> Jörn
>
> Am Mittwoch, 19. Juni 2024, 09:56:11 MESZ schrieb Ralph Lange via Tech-talk:
> > On Wed, 19 Jun 2024 at 08:53, Jörn Dreyer via Tech-talk <
> > tech-talk at aps.anl.gov> wrote:
> >
> > > Hi Folks,
> > >
> > > I encountered a strange problem with EPICS 7.0.8 under Ubuntu 22.04 on
> > > x86_64. My IOC crashes when loading ADBase.template:
> > >
> > > >dbLoadRecords("/home/srsi2d/EPICS/EPICS-7.0.8/modules/src/areaDetector/ADCore/db/ADBase.template",
> > > "P=WIZZLERHD:HZDR:,R=asicam3:,PORT=ASICAM3,ADDR=0,TIMEOUT=1")
> > > >epicsMutex pthread_mutex_unlock epicsMutexOsdUnlock failed: ERROR
> > > Operation not permitted
> > > >epicsMutex pthread_mutex_unlock epicsMutexOsdUnlock failed: ERROR
> > > Operation not permitted
> > > >*** buffer overflow detected ***: terminated
> > >
> > > The gdb backtrace shows the following:
> > >
> > > >#8 0x00007ffff7d0c9f9 in strcpy (__src=0x555555636cb0 "0",
> > > __dest=0x55555571a288 "")
> > > > at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:79
> > > >#9 dbAllocRecord
> > > > (pdbentry=pdbentry@entry=0x555555731348,
> > > precordName=precordName@entry=0x555555731288 "cam:SetAcquireBusy") at
> > > ../dbStatic/dbStaticRun.c:125
> > > >#10 0x00007ffff7d00d13 in dbCreateRecord
> > > > (pdbentry=pdbentry@entry=0x555555731348,
> > > precordName=precordName@entry=0x555555731288 "cam:SetAcquireBusy") at
> > > ../dbStatic/dbStaticLib.c:1441
> > > >#11 0x00007ffff7d07e67 in dbRecordHead
> > > > (visible=0, name=0x555555731288 "cam:SetAcquireBusy",
> > > recordType=0x5555557312e8 "calcout")
> > > > at ../dbStatic/dbLexRoutines.c:1132
> > > >#12 dbRecordHead
> > > > (recordType=0x5555557312e8 "calcout", name=0x555555731288
> > > "cam:SetAcquireBusy", visible=0)
> > > > at ../dbStatic/dbLexRoutines.c:1099
> > >
> > > If I comment out the calcout record it crashes at the next busy record. So
> > > it seems that my base installation has a problem, but why and what?
> > > The ai, ao, bi, bo and stringin records seem to work fine. The calcout and
> > > busy records are defined in my apps dbd file.
> > >
> > > Any idea what could be wrong?
> > >
> >
> > Yes.
> > This issue was detected last week (see
> > https://urldefense.us/v3/__https://github.com/epics-base/epics-base/issues/514__;!!G_uCfscf7eWS!fI4NqAWbBTj6edIyERFKemRmeMC7MdlaLJh4A-4jT3Jr6VurvZR74j0jrYms3MCrhw2OhAACdLLVMZqw_Y7oEsYVOEI$ ).
> >
> > Ubuntu 22.04 bumped the "-D_FORTIFY_SOURCE" level to 3, which causes EPICS
> > binaries to bail out because of an alleged "buffer overflow". The GCC
> > detection engine is getting triggered by specific pointer casting in Base.
> >
> > At this point, Michael provided a PR with a workaround. (
> > https://urldefense.us/v3/__https://github.com/epics-base/epics-base/pull/517__;!!G_uCfscf7eWS!fI4NqAWbBTj6edIyERFKemRmeMC7MdlaLJh4A-4jT3Jr6VurvZR74j0jrYms3MCrhw2OhAACdLLVMZqw_Y7oZC0EZGc$ )
> > Testing this PR would help us verify this change as a quick way out. (Given
> > the popularity of Ubuntu, this might justify a bugfix release of Base.)
> >
> > Other than that, I have no striking idea how to avoid the issue.
> >
> > Cheers,
> > ~Ralph
> >
>
>
>
- Replies:
- Re: Strange problem with EPICS areaDetector Michael Davidsaver via Tech-talk
- References:
- Strange problem with EPICS areaDetector Jörn Dreyer via Tech-talk
- Re: Strange problem with EPICS areaDetector Ralph Lange via Tech-talk
- Re: Strange problem with EPICS areaDetector Jörn Dreyer via Tech-talk
- Navigate by Date:
- Prev:
Re: AreaDetector Pva problem Jörn Dreyer via Tech-talk
- Next:
Re: AreaDetector Pva problem Mark Rivers via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
<2024>
- Navigate by Thread:
- Prev:
Re: Strange problem with EPICS areaDetector Jörn Dreyer via Tech-talk
- Next:
Re: Strange problem with EPICS areaDetector Michael Davidsaver via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
<2024>
|