journalctl list provides an -e option to list from the end, rather than the default start. Can I do the same in coredumpctl list? I ask because I've a lot of coredumps.

I am issuing the following commands: coredumpctl list Mon 2019-11-18 23:58:19 GMT 19043 1000 1000 31 missing /opt/google/chrome/chrome Mon 2019-11-18 23:58:19 GMT 19062 1000 1000 31 missing /opt/google/chrome/chrome Tue 2019-11-19 15:52:55 GMT 22332 1000 1000 6 missing /usr/bin/texstudio Followed by: coredumpctl gdb 22332 Storage: /var/lib/systemd/coredump/core.texstudio.1000.bb1cfb6b67f2423fac681d721ee1ba02.22332.1574178774000000.lz4 (inaccessible) File "/var/lib/systemd/coredump/core.texstudio.1000.bb1cfb6b67f2423fac681d721ee1ba02.22332.1574178774000000.lz4" is not readable: No such file or directory Which dumps the stack trace and gives the above two messages about storage being inaccessible and file not readable or found. Am I doing something wrong?

When a segmentation fault occurs in Linux, the error message Segmentation fault (core dumped) will be printed to the terminal (if any), and the program will be terminated. As a C/C++ dev, this happens to me quite often, and I usually ignore it and move onto gdb, recreating my previous action in order to trigger the invalid memory reference again. Instead, I thought I might be able to perhaps use this "core" instead, as running gdb all the time is rather tedious, and I cannot always recreate the segmentation fault. My questions are three: * Where is this elusive "core" dumped? * What does it contain? * What can I do with it?

I have core dump file and gdb. I can do gdb (gdb)bt This will give me backtrace but I want to do this using a shell script and in non-interactive mode. Writing

gdb exe core

takes me to gdb CLI and needs manual intervention. Any idea how can I automate it?

I'm currently running RHEL7. I haven't been able to find a definitive explanation of how to disable core dump files. I can limit to number of core files that are produced, but I don't know how to disable them entirely. I limited the number of core files that get generated by adding kernel.core_uses_pid = 0 kernel.core_pattern = core to /etc/sysctl.conf and running sudo sysctl -p This limits core file generation to a single file that gets rewritten each time there's a core dump. But I'd like to stop this file from being generated altogether. Thanks! EDIT: I also tried this: Add the line Storage:none to /etc/systemd/coredump.conf This didn't change anything, core files still get produced.

I'm looking for a way to remove any trace of old coredumps in coredumpctl list. At the moment it lists coredumps beginning at 2014-12-14 - I've updated software so often between then and now that I doubt those old coredumps are going to help me debug any problems now. Unfortunately removing the files from /var/lib/systemd/coredump only made the asterisk in the "PRESENT" column of coredumpctls output disappear. I couldn't find any way to remove all information about coredumps in the manpages or in the help output of coredumpctl.

so i am trying to check memory leak currently so i did some thread dump and heap dump for it i am using jdk11 command which is jstack & jmap the jstack command runs well, i can see the file in SFTP using Termius when i run the jmap command, this actually run as well saying

Dumping heap to /tmp/heap_dump_activemq.hprof ...
Heap dump file created [102526562 bytes in 0.318 secs]

when i checked the file in SFTP however it doesn't appear. when i tried to rerun the jmap command it said the file exists when i tried to move the file using mv it also said that the file or directory doesn't exist there is also sometimes this error message block when running the jmap

at jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:100)
at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58)
at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207)
at jdk.jcmd/sun.tools.jmap.JMap.executeCommandForPid(JMap.java:128)
at jdk.jcmd/sun.tools.jmap.JMap.dump(JMap.java:208)
at jdk.jcmd/sun.tools.jmap.JMap.main(JMap.java:114)

I was going to install my NVIDIA driver of NVIDIA-Linux-x86_64-565.77.run, and it showed > Unable to find the kernel source tree for the currently running kernel. Please make sure you have installed the kernel source files for your kernel and that they are properly configured; on Red Hat Linux systems, for example, be sure you have the 'kernel-source' or 'kernel-devel' RPM installed. If you know the correct kernel source files are installed, you may specify the kernel source path with the '--kernel-source-path' command line option. just like what happened in https://blog.csdn.net/chris_pei/article/details/79203033 . Following the instruction, I tried a simple yum install kernel-devel:

...
  Installing : 1:perl-parent-0.225-244.el7.noarch                                                                                                                                                              45/72 
  Installing : perl-HTTP-Tiny-0.033-3.el7.noarch                                                                                                                                                               46/72 
  Installing : perl-podlators-2.5.1-3.el7.noarch                                                                                                                                                               47/72 
  Installing : perl-Pod-Perldoc-3.20-4.el7.noarch                                                                                                                                                              48/72 
  Installing : 1:perl-Pod-Escapes-1.04-293.el7.noarch                                                                                                                                                          49/72 
  Installing : perl-Encode-2.51-7.el7.x86_64                                                                                                                                                                   50/72 
  Installing : perl-Text-ParseWords-3.29-4.el7.noarch                                                                                                                                                          51/72 
  Installing : perl-Pod-Usage-1.63-3.el7.noarch                                                                                                                                                                52/72 
  Installing : 4:perl-macros-5.16.3-293.el7.x86_64                                                                                                                                                             53/72 
  Installing : perl-Storable-2.45-3.el7.x86_64                                                                                                                                                                 54/72 
  Installing : perl-Exporter-5.68-3.el7.noarch                                                                                                                                                                 55/72 
  Installing : perl-constant-1.27-2.el7.noarch                                                                                                                                                                 56/72 
  Installing : perl-Time-Local-1.2300-2.el7.noarch                                                                                                                                                             57/72 
  Installing : perl-Socket-2.010-4.el7.x86_64                                                                                                                                                                  58/72 
  Installing : perl-Carp-1.26-244.el7.noarch                                                                                                                                                                   59/72 
  Installing : 4:perl-Time-HiRes-1.9725-3.el7.x86_64                                                                                                                                                           60/72 
  Installing : perl-PathTools-3.40-5.el7.x86_64                                                                                                                                                                61/72 
  Installing : perl-Scalar-List-Utils-1.27-248.el7.x86_64                                                                                                                                                      62/72 
  Installing : 1:perl-Pod-Simple-3.28-4.el7.noarch                                                                                                                                                             63/72 
  Installing : perl-File-Temp-0.23.01-3.el7.noarch                                                                                                                                                             64/72 
  Installing : perl-File-Path-2.09-2.el7.noarch                                                                                                                                                                65/72 
  Installing : perl-threads-shared-1.43-6.el7.x86_64                                                                                                                                                           66/72 
  Installing : perl-threads-1.87-4.el7.x86_64                                                                                                                                                                  67/72 
  Installing : perl-Filter-1.49-3.el7.x86_64                                                                                                                                                                   68/72 
  Installing : 4:perl-libs-5.16.3-293.el7.x86_64                                                                                                                                                               69/72 
  Installing : perl-Getopt-Long-2.40-3.el7.noarch                                                                                                                                                              70/72 
  Installing : 4:perl-5.16.3-293.el7.x86_64                                                                                                                                                                    71/72 
  Installing : kernel-devel-3.10.0-957.el7.x86_64                                                                                                                                                              72/72 
Non-fatal POSTIN scriptlet failure in rpm package kernel-devel-3.10.0-957.el7.x86_64
Non-fatal POSTTRANS scriptlet failure in rpm package p11-kit-trust-0.23.5-3.el7.x86_64
Non-fatal POSTTRANS scriptlet failure in rpm package centos-release-7-6.1810.2.el7.centos.x86_64

Installed:
  kernel-devel.x86_64 0:3.10.0-957.el7                                                                                                                                                                               

Dependency Installed:
  basesystem.noarch 0:10.0-7.el7.centos                bash.x86_64 0:4.2.46-31.el7                        centos-release.x86_64 0:7-6.1810.2.el7.centos         findutils.x86_64 1:4.5.11-6.el7                    
  gawk.x86_64 0:4.0.2-4.el7_3.1                        gdbm.x86_64 0:1.10-8.el7                           glibc.x86_64 0:2.17-260.el7                           glibc-common.x86_64 0:2.17-260.el7                 
  gmp.x86_64 1:6.0.0-15.el7                            grep.x86_64 0:2.20-3.el7                           groff-base.x86_64 0:1.22.2-8.el7                      info.x86_64 0:5.1-5.el7                            
  keyutils-libs.x86_64 0:1.5.8-3.el7                   krb5-libs.x86_64 0:1.15.1-34.el7                   libacl.x86_64 0:2.2.51-14.el7                         libattr.x86_64 0:2.4.46-13.el7                     
  libcap.x86_64 0:2.22-9.el7                           libcom_err.x86_64 0:1.42.9-13.el7                  libffi.x86_64 0:3.0.13-18.el7                         libgcc.x86_64 0:4.8.5-36.el7                       
  libselinux.x86_64 0:2.5-14.1.el7                     libsepol.x86_64 0:2.5-10.el7                       libstdc++.x86_64 0:4.8.5-36.el7                       libtasn1.x86_64 0:4.10-1.el7                       
  libverto.x86_64 0:0.2.5-4.el7                        ncurses.x86_64 0:5.9-14.20130511.el7_4             ncurses-base.noarch 0:5.9-14.20130511.el7_4           ncurses-libs.x86_64 0:5.9-14.20130511.el7_4        
  nspr.x86_64 0:4.19.0-1.el7_5                         nss-softokn-freebl.x86_64 0:3.36.0-5.el7_5         nss-util.x86_64 0:3.36.0-1.el7_5                      p11-kit.x86_64 0:0.23.5-3.el7                      
  p11-kit-trust.x86_64 0:0.23.5-3.el7                  pcre.x86_64 0:8.32-17.el7                          perl.x86_64 4:5.16.3-293.el7                          perl-Carp.noarch 0:1.26-244.el7                    
  perl-Encode.x86_64 0:2.51-7.el7                      perl-Exporter.noarch 0:5.68-3.el7                  perl-File-Path.noarch 0:2.09-2.el7                    perl-File-Temp.noarch 0:0.23.01-3.el7              
  perl-Filter.x86_64 0:1.49-3.el7                      perl-Getopt-Long.noarch 0:2.40-3.el7               perl-HTTP-Tiny.noarch 0:0.033-3.el7                   perl-PathTools.x86_64 0:3.40-5.el7                 
  perl-Pod-Escapes.noarch 1:1.04-293.el7               perl-Pod-Perldoc.noarch 0:3.20-4.el7               perl-Pod-Simple.noarch 1:3.28-4.el7                   perl-Pod-Usage.noarch 0:1.63-3.el7                 
  perl-Scalar-List-Utils.x86_64 0:1.27-248.el7         perl-Socket.x86_64 0:2.010-4.el7                   perl-Storable.x86_64 0:2.45-3.el7                     perl-Text-ParseWords.noarch 0:3.29-4.el7           
  perl-Time-HiRes.x86_64 4:1.9725-3.el7                perl-Time-Local.noarch 0:1.2300-2.el7              perl-constant.noarch 0:1.27-2.el7                     perl-libs.x86_64 4:5.16.3-293.el7                  
  perl-macros.x86_64 4:5.16.3-293.el7                  perl-parent.noarch 1:0.225-244.el7                 perl-podlators.noarch 0:2.5.1-3.el7                   perl-threads.x86_64 0:1.87-4.el7                   
  perl-threads-shared.x86_64 0:1.43-6.el7              popt.x86_64 0:1.13-16.el7                          sed.x86_64 0:4.2.2-5.el7                              setup.noarch 0:2.8.71-10.el7                       
  tzdata.noarch 0:2018e-3.el7                          zlib.x86_64 0:1.2.7-18.el7                        

Failed:
  ca-certificates.noarch 0:2018.2.22-70.0.el7_5        chkconfig.x86_64 0:1.7.4-1.el7        coreutils.x86_64 0:8.22-23.el7        filesystem.x86_64 0:3.2-25.el7        openssl-libs.x86_64 1:1.0.2k-16.el7       

Complete!

(Full version in https://blog.csdn.net/Sakura_no_ame/article/details/145215254?sharetype=blogdetail&sharerId=145215254&sharerefer=PC&sharesource=Sakura_no_ame&spm=1011.2480.3001.8118) However, after that most of the commands failed with segment fault (core dumped), even like simple ls, rm, cp and mv, except for some built-in-shell commands like cd, ulimit and history. There are two important hints which I think to be possible to be the cause: 1. My Linux kernel version is 3.10.0-1160.42.2.el7.x86_64, which seems to mismatch with the version I have installed as kernel-devel.x86_64 0:3.10.0-957.el7. 2. I ran the code in a confused state following https://blog.csdn.net/chris_pei/article/details/79203033 :

wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.13/linux-headers-4.13.0-041300_4.13.0-041300.201709031731_all.deb 
wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.13/linux-headers-4.13.0-041300-generic_4.13.0-041300.201709031731_amd64.deb 
wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.13/linux-image-4.13.0-041300-generic_4.13.0-041300.201709031731_amd64.deb 
sudo dpkg -i *.deb

But I have never made any settings for the boot stuff because I found it unnecessary. So I am eager to know: 1. What caused my Segment fault (core dumped). 2. What should I do to recover my computer without any tools like cp, rm and mv. **What I have tried**: I can upload or download files to /workspace because I am using Jupyter to access my computer. I have tried to upload a simple program to a catch core dumped file so that I can analyze the cause with gdb program core. Unluckily, I have no idea granting execution permissions to the program because whenever I typed a chmod command, it still showed Segment fault (core dumped). I will appreciate any help or advice because it is very important to me. Thank you very much. --- I will provide all of the commands I have typed from history: https://blog.csdn.net/Sakura_no_ame/article/details/145215241?sharetype=blogdetail&sharerId=145215241&sharerefer=PC&sharesource=Sakura_no_ame&spm=1011.2480.3001.8118

I am doing some programming, and I want to have core dumps disabled by default and only enabled when the soft limit is increased using ulimit -c unlimited. I am trying to disable core dumps by default by having the following settings in the /etc/security/limits.conf file:

*               hard    core            unlimited
*               soft    core            0

After restarting and logging in, core dumps are still generated despite the fact that running ulimit -c gives 0. Setting the hard limit using ulimit -Hc 0 disables the core dumps, but I would like to use soft limits to disable core dumps. I would like to know why soft limits are being ignored in this case, and how to enforce these soft limits.

I am working in an embedded Linux system, and now I want to trigger a core dump from within kernel by using send_sig(task, SIGSEGV, 1). There is a process A having 10 threads, occasionally, there is a kernel oops occurred and at that time, one thread of A is the current process reported by kernel. So I want to dump the core of the process A to find out what happened. So I did followings. 1. Enable core dump in kernel configuration. 2. Running ulimit -c unlimited in init script. 3. echo '/mnt/core.%p.%e' > /proc/sys/kernel/core_pattern. 4. Changed the kernel oops codes to call send_sig(task_A, SIGSEGV, 1) to send SIGSEGV to the process A. Then I tried to reproduce the kernel oops, and I found the log of Segmentation Fault from process A, but I did NOT see any core dumped in /mnt/. If I changed the process A to access 0 of address, it can trigger a core dump correctly. Why it failed to dump core from my kernel codes (the process A did is killed by SIGSEGV)? And how can I trigger a core-dump to capture the user space context in the case of kernel oops???

I'm investigating why my core dump files are being deleted on every reboot. I checked the /etc/tmpfiles.d/ directory and it is empty. I checked /usr/lib/tmpfiles.d/systemd.conf and found: # Handle lost systemd-coredump temp files. They could be lost on old filesystems, # for example, after hard reboot. x /var/lib/systemd/coredump/.#core*.%b* r! /var/lib/systemd/coredump/.#* I'm trying to understand the man file, but it looks like the first line says exclude the /var/lib/systemd/coredump/XXX directory altogether. (I don't understand the .#core.\*.%b* syntax). And the second line says remove empty directories at /var/lib/systemd/coredump/XXX and recurse. (Again, the suffix I can't explain). Would either of these two lines be deleting my coredump files on every reboot? Would I solve the problem by copying the systemd.conf file to /etc/tmpdilfes.d/coredump.conf and change as follows: x /var/lib/systemd/coredump/.#core*.%b* 0755 root root 20d r! /var/lib/systemd/coredump/.#* 0755 root root 20d

Once a month I find one of my RedHat 9 servers has rebooted (actually it's AlmaLinux 9 but since it's a clone of RH9 this question is probably better to solve in the context of RH9). I'm trying to find out what is causing the crash, but there are no core dump files created! I have followed the instructions in this post , except that I don't seem to have anything *apport* on my system, but when I trigger a core dump with: > sleep 3 & kill -SEGV $! there is no core dump file! I confirmed the basics are set with: [root@myhost ~]# cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h [root@myhost ~]# ulimit -c unlimited Is there something else I must set to let the dump file be created? I suspect my own app (non-packaged) is causing the problem...but there is no core file even in the directory holding the app. **====UPDATE====** I modified /etc/coredump.conf and set storage=external (everything else commented out), then rebooted and ran the following: [root@myhost ~]# sleep 3 & kill -SEGV $! [1] 3583 [root@myhost ~]# [1] + Segmentation fault (core dumped) sleep 3 [root@myhost ~]# coredumpctl --all TIME PID UID GID SIG COREFILE EXE SIZE Sat 2024-10-26 12:56:46 EDT 3583 0 0 SIGSEGV none /usr/bin/bash - [root@myhost ~]# ll /var/lib/systemd/coredump/ total 0 So still no core dump files visible (and notice the "none" above). The system log shows: Oct 26 13:06:41 ngcvls1 systemd[1] : Started Process Core Dump (PID 4459/UID 0). Oct 26 13:06:41 ngcvls1 systemd-coredump: Resource limits disable core dumping for process 4458 (bash). Oct 26 13:06:41 ngcvls1 systemd-coredump: Process 4458 (bash) of user 0 dumped core. So from the command line I ran: ulimit -c unlimited and repeated the segfault test, then a core file was created! But on reboot it was gone. (Despite my having storage=external set in coredump.conf). I need core dumps to survive reboots otherwise I can't tell why my system crashed. Getting closer! I would like to make ulimit -c permanent, just not sure where to put that (don't like advice of other posts to put in .bashrc)

Generating coredumps used to work fine, but after switching over to systemd, I only see the message Aborted (core dumped) but no core file is generated. Has it something to do with systemd? (Background: My original question can be found here . Thanks schaiba for finding the solution. I provide this Q&A, so others can find the solution easier if they already know that it is a systemd issue.)

I am trying to enable systemd coredumps containing call stacks with function names when printed with coredumpctl info, so that I can get a call stack without using gdb and/or coredumpctl debug (since my real target has no debugger installed). Thus I want to use only coredumpctl info. Using Fedora 39, I installed the package tftp-server, and tested coredumps by starting tftpd (systemctl start tftp), and sending kill -SEGV to the process /usr/sbin/in.tftpd . I then see that coredumps created that way contain the function names inside the in.tftpd process (Fedora enables minidebuginfo/gnu_debugdata by default). However, when I do the same thing using a test C file which I compiled with debug symbols, I see that my test coredumps show n/a for the function names in my process (I tried with full debug symbols as well as with only minidebuginfo/gnu_debugdata). What do I need to do so that my application also generates proper coredumps, like it is doing for binaries installed by Fedora packages? * Test code (file test.c):

-C
    #include 
    #include 
    
    int test123()
    {
        printf("test123\n");
        sleep(1);
    }
    
    int main()
    {
        for (;;) {
            test123();
        }
    }

* Test Makefile:

all:
    	gcc ./test.c -o test-with-symbols -g

* coredumpctl info of in.tftpd looks good on Fedora (it shows the function name main in in.tftpd):

-shellsession
    $ coredumpctl info 4335
               PID: 4335 (in.tftpd)
               UID: 0 (root)
               GID: 0 (root)
            Signal: 11 (SEGV)
         Timestamp: Mon 2023-11-20 06:07:08 EST (1h 36min ago)
      Command Line: /usr/sbin/in.tftpd -s /var/lib/tftpboot
        Executable: /usr/sbin/in.tftpd
     Control Group: /system.slice/tftp.service
              Unit: tftp.service
             Slice: system.slice
           Boot ID: 954e4f02e86e4f6498987e2e202d0413
        Machine ID: 28dd14ccbe5b46018201dd25d5a60e94
          Hostname: localhost-live
           Storage: /var/lib/systemd/coredump/core.in\x2etftpd.0.954e4f02e86e4f6498987e2e202d0413.4335.1700478428000000.zst (missing)
           Package: tftp/5.2-41.fc39
          build-id: 438daef3ffb345cc3c791def1ceba465865929f6
           Message: Process 4335 (in.tftpd) of user 0 dumped core.
                    
                    Module in.tftpd from rpm tftp-5.2-41.fc39.x86_64
                    Stack trace of thread 4335:
                    #0  0x00007ffb2640ef8e __select (libc.so.6 + 0x112f8e)
                    #1  0x00005578d0fde699 main (in.tftpd + 0x4699)
                    #2  0x00007ffb2632414a __libc_start_call_main (libc.so.6 + 0x2814a)
                    #3  0x00007ffb2632420b __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2820b)
                    #4  0x00005578d0fdfa15 _start (in.tftpd + 0x5a15)
                    ELF object binary architecture: AMD x86-64

* codedumpctl info of my test binary shows n/a instead of function names. I tested this on Fedora 39 and on Ubuntu 22.04 (systemd version 254 on Fedora 39, systemd version 249 on Ubuntu 22.04):

-shellsession
    liveuser@localhost-live:~/Downloads/test$ coredumpctl info 8485
               PID: 8485 (test)
               UID: 1000 (liveuser)
               GID: 1000 (liveuser)
            Signal: 11 (SEGV)
         Timestamp: Mon 2023-11-20 07:26:38 EST (54s ago)
      Command Line: ./test
        Executable: /home/liveuser/Downloads/test/test
     Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.gnome.Terminal.slice/vte-spawn-07143dc2-3f50-4778-a60f-e027a4bb85e9.scope
              Unit: user@1000.service
         User Unit: vte-spawn-07143dc2-3f50-4778-a60f-e027a4bb85e9.scope
             Slice: user-1000.slice
         Owner UID: 1000 (liveuser)
           Boot ID: 954e4f02e86e4f6498987e2e202d0413
        Machine ID: 28dd14ccbe5b46018201dd25d5a60e94
          Hostname: localhost-live
           Storage: /var/lib/systemd/coredump/core.test.1000.954e4f02e86e4f6498987e2e202d0413.8485.1700483198000000.zst (present)
      Size on Disk: 17.9K
           Message: Process 8485 (test) of user 1000 dumped core.
                    
                    Stack trace of thread 8485:
                    #0  0x00007f8a5b4bd127 clock_nanosleep@GLIBC_2.2.5 (libc.so.6 + 0xd9127)
                    #1  0x00007f8a5b4cf9f7 __nanosleep (libc.so.6 + 0xeb9f7)
                    #2  0x00007f8a5b4e1333 sleep (libc.so.6 + 0xfd333)
                    #3  0x0000558c6c9a118a n/a (/home/liveuser/Downloads/test/test + 0x118a)
                    #4  0x0000558c6c9a119f n/a (/home/liveuser/Downloads/test/test + 0x119f)
                    #5  0x00007f8a5b40c14a __libc_start_call_main (libc.so.6 + 0x2814a)
                    #6  0x00007f8a5b40c20b __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2820b)
                    #7  0x0000558c6c9a10a5 n/a (/home/liveuser/Downloads/test/test + 0x10a5)
                    ELF object binary architecture: AMD x86-64

All of the discussion I have seen regarding enabling core dumps on Centos 7 seem to assume that you are root, and you are enabling core dumps systemwide. Can I, as a user, enable core dumps just for myself, dumping the core file in my own home directory? Or is this something that can only be done by root? Also: is this a problem unique to Centos?

I'm a chemist using a computational chemistry software called **Gaussrate**, and I'm encountering a segmentation fault that I don't know how to resolve. I have very limited knowledge of programming or debugging, so I'm seeking guidance on how to diagnose and fix this issue. Below is the error message and backtrace that I received: Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x149091fee171 in ??? #1 0x149091fed313 in ??? #2 0x14909125db4f in ??? #3 0x4c9b9a in ??? #4 0x4d9860 in ??? #5 0x4f8827 in ??? #6 0x50692d in ??? #7 0x506ac1 in ??? #8 0x149091249d84 in ??? #9 0x401a7d in ??? #10 0xffffffffffffffff in ??? Segmentation fault (core dumped) **Details:** **Operating System:** Running on a Linux environment **Context:** The segmentation fault occurs during the execution of a scientific computation in Gaussrate. **Questions**: 1. As a chemist with no programming experience, what tools or methods can I use to understand where the segmentation fault is occurring? 2. Based on the backtrace, what could be the likely causes of this segmentation fault? Are there common issues related to invalid memory references that I should check? 4. Any general advice on how to handle and debug segmentation faults on Linux, especially for someone without a programming background, would be greatly appreciated. Thank you in advance for your help!

I'm running kernel 2.6.35 on a custom embedded device (ARMv7). I'm trying to get a core dump but it appears core dumps are disabled. My kernel config can be found here: https://pastebin.com/XXZ8YyaA My test application is the following: int main() { return 1/0; } I expect the following: Floating point exception (core dumped) But instead get this: Floating point exception Meaning core dumps are disabled. How can I enable them for my platform? It looks like the option to toggle functionality in the kernel CONFIG_COREDUMP wasn't added till kernel version 3.7 . Is it not always enabled in previous kernels? # ulimit -a -t: cpu time (seconds) unlimited -f: file size (blocks) unlimited -d: data seg size (kbytes) unlimited -s: stack size (kbytes) 8192 -c: core file size (blocks) unlimited -m: resident set size (kbytes) unlimited -u: processes 1710 -n: file descriptors 1024 -l: locked-in-memory size (kbytes) 64 -v: address space (kbytes) unlimited -x: file locks unlimited -i: pending signals 1710 -q: bytes in POSIX msg queues 819200 -e: max nice 0 -r: max rt priority 0 -N 15: unlimited # ./crash Floating point exception

I'm trying to analyze core dump files of the systemd process, but encountering errors due to missing symbols. Can anyone advise what debug symbols need to be installed to successfully analyze these core dumps?

gdb  -e /usr/lib/systemd/systemd-journald -c core-systemd-journal--0-0-657-1718434887
GNU gdb (GDB) Red Hat Enterprise Linux 8.2-20.el8
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
    .

For help, type "help".
Type "apropos word" to search for commands related to "word".

warning: core file may not match specified executable file.
[New LWP 657]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Missing separate debuginfo for /lib64/libuuid.so.1
Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/d0/43572678e11cfb56aecb4ec534bc016de8d0d5.debug
Missing separate debuginfo for /lib64/libudev.so.1
Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/94/5e15d6b231fc346823186cd70e886dede771ca.debug
Core was generated by `/usr/lib/systemd/systemd-journald'.
Program terminated with signal SIGABRT, Aborted.

I have this in my /etc/security/limits.conf:

*                soft    core            unlimited
*                hard    core            unlimited

And no other files in /etc/security/limits.d. Added session required pam_limits.so in /etc/pam.d/common-session and /etc/pam.d/common-session-noninteractive. After re-login and reboot, the output of ulimit -c is always 0. But ulimit -c 100000 or ulimit -c unlimited works.（I don't want to use this ad hoc approach.）

I’ve been working with the database for over a year, but after rebooting the server I can’t start postgresql:

# sudo systemctl start postgresql
Job for postgresql.service failed because a fatal signal was delivered causing the control process to dump core.
See "systemctl status postgresql.service" and "journalctl -xe" for details.

# sudo systemctl status postgresql
● postgresql.service - PostgreSQL database server
   Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled; vendor preset: disabled)
   Active: failed (Result: core-dump) since Fri 2024-05-24 10:51:52 +03; 44s ago
  Process: 4805 ExecStart=/usr/bin/postmaster -D ${PGDATA} (code=dumped, signal=ILL)
  Process: 4803 ExecStartPre=/usr/libexec/postgresql-check-db-dir postgresql (code=exited, status=0/SUCCESS)
 Main PID: 4805 (code=dumped, signal=ILL)

# journalctl -xe

May 24 10:51:44 hitriy systemd: Starting PostgreSQL database server...
May 24 10:51:52 hitriy systemd: postgresql.service: Main process exited, code=dumped, status=4/ILL
May 24 10:51:52 hitriy systemd: postgresql.service: Failed with result 'core-dump'.
May 24 10:51:52 hitriy systemd: Failed to start PostgreSQL database server.

May 24 10:51:52 hitriy systemd-coredump: Resource limits disable core dumping for process 4805 (postmaster). May 24 10:51:52 hitriy systemd-coredump: Process 4805 (postmaster) of user 26 dumped core. -- Subject: Process 4805 (postmaster) dumped core -- Defined-By: systemd -- Support: https://access.redhat.com/support -- Documentation: man:core(5) -- -- Process 4805 (postmaster) crashed and dumped core. -- -- This usually indicates a programming error in the crashing program and -- should be reported to its vendor as a bug. May 24 10:51:52 hitriy systemd: postgresql.service: Main process exited, code=dumped, status=4/ILL May 24 10:51:52 hitriy systemd: postgresql.service: Failed with result 'core-dump'. -- Subject: Unit failed -- Defined-By: systemd -- Support: https://access.redhat.com/support -- -- The unit postgresql.service has entered the 'failed' state with result 'core-dump'. May 24 10:51:52 hitriy systemd: Failed to start PostgreSQL database server. ``` Whats wrong? Please help me!!!