Core dump file is not generated

前端 未结 13 668
情书的邮戳
情书的邮戳 2020-11-28 06:46

Every time, my application crash a core dump file is not generated. I remember that few days ago, on another server it was generated. I\'m running the app u

相关标签:
13条回答
  • 2020-11-28 07:04

    In centos,if you are not root account to generate core file: you must be set the account has a root privilege or login root account:

    vim /etc/security/limits.conf

    account soft core unlimited
    account hard core unlimited

    then if you in login shell with securecrt or other:

    logout and then relogin

    0 讨论(0)
  • 2020-11-28 07:13

    Also, check to make sure you have enough disk space on /var/core or wherever your core dumps get written. If the partition is almos full or at 100% disk usage then that would be the problem. My core dumps average a few gigs so you should be sure to have at least 5-10 gig available on the partition.

    0 讨论(0)
  • 2020-11-28 07:16

    Just in case someone else stumbles on this. I was running someone else's code - make sure they are not handling the signal, so they can gracefully exit. I commented out the handling, and got the core dump.

    0 讨论(0)
  • 2020-11-28 07:17

    This link contains a good checklist why core dumps are not generated:

    • The core would have been larger than the current limit.
    • You don't have the necessary permissions to dump core (directory and file). Notice that core dumps are placed in the dumping process' current directory which could be different from the parent process.
    • Verify that the file system is writeable and have sufficient free space.
    • If a sub directory named core exist in the working directory no core will be dumped.
    • If a file named core already exist but has multiple hard links the kernel will not dump core.
    • Verify the permissions on the executable, if the executable has the suid or sgid bit enabled core dumps will by default be disabled. The same will be the case if you have execute permissions but no read permissions on the file.
    • Verify that the process has not changed working directory, core size limit, or dumpable flag.
    • Some kernel versions cannot dump processes with shared address space (AKA threads). Newer kernel versions can dump such processes but will append the pid to the file name.
    • The executable could be in a non-standard format not supporting core dumps. Each executable format must implement a core dump routine.
    • The segmentation fault could actually be a kernel Oops, check the system logs for any Oops messages.
    • The application called exit() instead of using the core dump handler.
    0 讨论(0)
  • 2020-11-28 07:18

    Remember if you are starting the server from a service, it will start a different bash session so the ulimit won't be effective there. Try to put this in your script itself:

    ulimit -c unlimited
    
    0 讨论(0)
  • 2020-11-28 07:18

    For the record, on Debian 9 Stretch (systemd), I had to install the package systemd-coredump. Afterwards, core dumps were generated in the folder /var/lib/systemd/coredump.

    Furthermore, these coredumps are compressed in the lz4 format. To decompress, you can use the package liblz4-tool like this: lz4 -d FILE.

    To be able to debug the decompressed coredump using gdb, I also had to rename the utterly long filename into something shorter...

    0 讨论(0)
提交回复
热议问题