Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  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  <20182019 
<== Date ==> <== Thread ==>

Subject: Problem with autosave module making it crash at random basis.
From: "Abdalla Ahmad" <abdalla.ahmad@sesame.org.jo>
To: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
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

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  <20182019 
Navigate by Thread:
Prev: Re: TeledyneIsco Foxy R2 Fraction Collector giles.knap@diamond.ac.uk
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  <20182019 
ANJ, 10 Apr 2018 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·