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: | Re: IOC crash |
From: | "Ronald L. Sluiter" <[email protected]> |
To: | Hinko Kocevar <[email protected]> |
Cc: | "[email protected]" <[email protected]> |
Date: | Mon, 22 Jan 2018 11:10:43 -0600 |
If you can re-create the problem using the "linux-x86_64-debug" architecture, then you can use a source-code debugger (e.g., gdb or ddd) to diagnose it. You would need to place an assembly-code
level breakpoint in the assert() code to determine why the assert() failed. Ron On 01/19/2018 10:35 AM, Hinko Kocevar wrote:
Thanks again! I can see that if I run a faulty app that would trigger core dump the file is saved into /var/spool/abrt folder. I can not see IOC core dump there.. Might be due to redhat/centos abrt service default settings that only saves core dump if the package was installed using yum or similar. My IOC was not. This, I changed now, but that means I need to reproduce the crash. Will update you on the progress. /Hinko On Fri, Jan 19, 2018 at 4:17 PM, Michael Davidsaver <[email protected]> wrote:On 01/19/2018 12:31 AM, Hinko Kocevar wrote:if core saving was enabled at the time of the crash..Runulimit -aand look for a line like:core file size (blocks, -c) 0If this is zero, then core dumps are disabled. Runulimit -c unlimitedTo enable core dumps. You can use a non-zero value to limit the core file size, but that's probably not relevant unless your IOC is using a _lot_ of memory.