Hi
One of our IOCs crashed and it appears to do so from time to time. I used valgrind on the IOC process and the attached file contains valgrind output right when the IOC crashed. The
first 2 lines are the IOC shell output before the segmentation fault happened. I could not figure out whether the problem from the module sending something corrupted to the printf functions or the standard C library itself is somehow corrupted. I tried cloning
the latest autosave version from github but the build failed. Build output is in the attached too.
OS: Scientific Linux 6.4 32-bit.
EPICS: 3.14.12.3
SynApps 5.6
Autosave 4.8
Best Regards,
Abdalla Ahmad
Control Engineer
SESAME
Allan, Jordan.
Tel: (+962-5) 3511348 , ext. 265
Fax: (+962-5) 3511423
Mob: (+962-7)88183296
www.sesame.org.jo
|
IOC Shell:
save_restore:do_seq - '/home/control/autosave/rf.sav' not found. Writing a new one. [180407-085621]
save_restore:write_save_file: Backup file (/home/control/autosave/rf.savB) bad or not found. Writing a new one. [180407-085621]
Valgrind:
==4889== by 0x421F7F9: start_routine (osdThread.c:385)
==4889== by 0xDE6A48: start_thread (in /lib/libpthread-2.12.so)
==4889== by 0xCF6AAD: clone (in /lib/libc-2.12.so)
==4889== Address 0x46 is not stack'd, malloc'd or (recently) free'd
==4889==
==4889==
==4889== Process terminating with default action of signal 11 (SIGSEGV)
==4889== Access not within mapped region at address 0x46
==4889== at 0xC54A75: vfprintf (in /lib/libc-2.12.so)
==4889== by 0xC5F42E: fprintf (in /lib/libc-2.12.so)
==4889== by 0x40D2511: write_it (save_restore.c:1371)
==4889== by 0x40D4B85: write_save_file (save_restore.c:1601)
==4889== by 0x40D52C1: do_seq (save_restore.c:1706)
==4889== by 0x40D891F: save_restore (save_restore.c:852)
==4889== by 0x421F7F9: start_routine (osdThread.c:385)
==4889== by 0xDE6A48: start_thread (in /lib/libpthread-2.12.so)
==4889== by 0xCF6AAD: clone (in /lib/libc-2.12.so)
==4889== If you believe this happened as a result of a stack
==4889== overflow in your program's main thread (unlikely but
==4889== possible), you can try to increase the size of the
==4889== main thread stack using the --main-stacksize= flag.
==4889== The main thread stack size used in this run was 10485760.
==4889==
==4889== HEAP SUMMARY:
==4889== in use at exit: 1,374,958,286 bytes in 9,559,234 blocks
==4889== total heap usage: 203,610,820 allocs, 194,051,586 frees, 685,977,589,825 bytes allocated
==4889==
==4889==
==4889== Valgrind's memory management: out of memory:
==4889== newSuperblock's request for 38240256 bytes failed.
==4889== 3113762816 bytes have already been allocated.
==4889== Valgrind cannot continue. Sorry.
==4889==
==4889== There are several possible reasons for this.
==4889== - You have some kind of memory limit in place. Look at the
==4889== output of 'ulimit -a'. Is there a limit on the size of
==4889== virtual memory or address space?
==4889== - You have run out of swap space.
==4889== - Valgrind has a bug. If you think this is the case or you are
==4889== not sure, please let us know and we'll try to fix it.
==4889== Please note that programs can take substantially more memory than
==4889== normal when running under Valgrind tools, eg. up to twice or
==4889== more, depending on the tool. On a 64-bit machine, Valgrind
==4889== should be able to make use of up 32GB memory. On a 32-bit
==4889== machine, Valgrind should be able to use all the memory available
==4889== to a single process, up to 4GB if that's how you have your
==4889== kernel configured. Most 32-bit Linux setups allow a maximum of
==4889== 3GB per process.
==4889==
==4889== Whatever the reason, Valgrind cannot continue. Sorry.
Autosave Build:
../dbrestore.c:1563: error: expected â??=â??, â??,â??, â??;â??, â??asmâ?? or â??__attribute__â?? before â??previousHookâ??
../dbrestore.c: In function â??myDbLoadRecordsHookâ??:
../dbrestore.c:1594: error: â??previousHookâ?? undeclared (first use in this function)
../dbrestore.c:1594: error: (Each undeclared identifier is reported only once
../dbrestore.c:1594: error: for each function it appears in.)
../dbrestore.c:1594: warning: implicit declaration of function â??previousHookâ??
../dbrestore.c: In function â??autosaveBuildâ??:
../dbrestore.c:1652: error: â??previousHookâ?? undeclared (first use in this function)
../dbrestore.c:1652: error: â??dbLoadRecordsHookâ?? undeclared (first use in this function)
make[3]: *** [dbrestore.o] Error 1
make[3]: Leaving directory `/home/control/epics/support/synApps_5_6/support/autosave/asApp/src/O.linux-x86'
make[2]: *** [install.linux-x86] Error 2
make[2]: Leaving directory `/home/control/epics/support/synApps_5_6/support/autosave/asApp/src'
make[1]: *** [src.install] Error 2
make[1]: Leaving directory `/home/control/epics/support/synApps_5_6/support/autosave/asApp'
make: *** [asApp.install] Error 2
- Replies:
- Re: Problem with autosave module making it crash at random basis. Mark Rivers
- Re: Problem with autosave module making it crash at random basis. Michael Davidsaver
- Navigate by Date:
- Prev:
RE: Simple channel access write program within Qt Abdalla Ahmad
- Next:
Re: Problem with autosave module making it crash at random basis. Mark Rivers
- 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: TeledyneIsco Foxy R2 Fraction Collector [email protected]
- Next:
Re: Problem with autosave module making it crash at random basis. Mark Rivers
- 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
|