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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Problem with autosave module making it crash at random basis. |
From: | "Abdalla Ahmad" <[email protected]> |
To: | "[email protected]" <[email protected]> |
Date: | Sun, 8 Apr 2018 06:06:33 +0000 |
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 |
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