There are a couple of ways of capturing a core dump on Linux to help us analyze problems.
- Attach to SlickEdit with gdb:
- Find the process ID for the SlickEdit executable: ps -ef | grep vs_exe
- gdb -p process-id
- At the gdb prompt, generate the core dump by invoking the "generate-core-file" command.
After using this command, it should return you output: Saved corefile core.process-id
- Attach to SlickEdit with lldb (if available, also works for macOS):
- Find the process ID for the SlickEdit executable: ps -ef | grep vs_exe
- lldb -p process-id
- At the lldb prompt, generate the core dump by invoking the command: process save-core <path>
- The traditional method is for Linux to write a "core" file in the working directory.
However, most newer Linux distributions have this behavior disabled by default.
- Depending on your Linux distribution, you can enable core dumps or find out where they are saved using some of the following settings:
- Use ulimit to allow SlickEdit to create a core dump: ulimit -S -c unlimited vs_exe
- Set a system limit in /etc/security/limits.conf. : soft core unlimited</li>
- Check ulimit settings
- hard limit: ulimit -H -c
- soft limit: ulimit -S -c
- Check the core pattern. Use the /proc file system to gather the value and change it temporarily during testing:
cat /proc/sys/kernel/core_pattern
If you prefer using sysctl, then query the kernel.core_pattern key.
It might show something like this: |/usr/share/apport/apport %p %s %c %P
In this case, a crash will be piped to the apport utility. So this means that crashes are going to be analyzed by Apport. Normally crashes are found in /var/crash, but may also be in /var/spool or /var/lib/systemd/coredump on other Linux distributions.
The core file may be pretty large, so it is preferred that you zip up the core file before uploading/sending/posting.