Truncated core dumps with TC17

[dspence]

Hi all,

I have been using the following settings on TC13 to get useful core dumps (thanks to Rich for helping me out):

This is in an application's startup script:
   # Set the core dump file size limit.
   # Limit each dump to 781250 blocks of 512 bytes, i.e. 400 MB.
   ulimit -c 781250

This is in bootlocal.sh:
   # Write all core dumps to /data/coredumps. Attach the name of the executable to the file name.
   # This way, the system will always store *only the latest* core dump of each executable.
   mkdir -p /data/coredumps
   chmod 1777 /data/coredumps
   sysctl -w kernel.core_pattern='/data/coredumps/core.%e'

The drive that the /data/ link points to has over 200 GB of free space, so the truncation is not happening because of limited space in the target location.

With Tiny Core 13 this worked well.  With Tiny Core 17 this results in small "truncated" core files.

I tried changing to use "ulimit -c unlimited" and that didn't help.

For comparison, the same program on TC13 generates a core file about 156 MB in size, and on TC17 it generates a file about 73 KB in size.  Maybe these weren't from the same crash but in general that's what the sizes look like.  With GDB I can see the stack trace on TC13 and on TC17 it gives messages like "warning: BFD: warning: /mnt/sda1/coredumps/core.test has a segment extending past end of file" and "warning: failed to parse execution context from corefile: Cannot access memory at address 0x7fffbba85fe0", "Failed to read a valid object file image from memory", "Backtrace stopped: Cannot access memory at address 0x7fffbba837f8", etc.

Is there another setting I have to change?

Thanks.

[Rich]

Hi dspence
I'm afraid I don't have any good answers for you, but maybe
a few ideas to try to make some progress on this.

Maybe the contents of dmesg can provide some insight by
saving a copy when the coredump occurs.

Maybe use  inotifywait  to monitor  /data/coredumps  for a
file to be created, and then trigger:

Code: [Select]

dmesg > dmesg$(date +%F-%T).txtThat should create  dmesgYYYYMMDD-HH:MM:SS.txt  every
time a coredump occurs.

If you need help with that, I can provide a sample of how I
used  inotifywait  to trigger a command when a file gets created.

I also found this about using  gdb  to generate a coredump file:
https://stackoverflow.com/a/79434751

[Rich]

Hi dspence

... If you need help with that, I can provide a sample of how I
used  inotifywait  to trigger a command when a file gets created. ...

I decide to create a script that does what I described in my previous post.
The script is called  WatchDirectory.sh

Code: [Select]

tc@E310:~/Scripting/WatchDirectory$ ls -l
total 4
-rwxrwxr-x 1 tc staff 2929 Jul  4 11:26 WatchDirectory.sh
The scripts variable  Dir1  tells it which directory to monitor.

Code: [Select]

Dir1="/home/tc/Scripting/WatchDirectory/"Full paths are recommended.

Here I launch the script in the background and create 4 files.

Code: [Select]

tc@E310:~/Scripting/WatchDirectory$ ./WatchDirectory.sh &
tc@E310:~/Scripting/WatchDirectory$ touch File1 File2 File3 File4
tc@E310:~/Scripting/WatchDirectory$ ls -l
total 8
drwxr-sr-x 2 tc staff 4096 Jul  4 13:20 Dmesg/
-rw-r--r-- 1 tc staff    0 Jul  4 13:20 File1
-rw-r--r-- 1 tc staff    0 Jul  4 13:20 File2
-rw-r--r-- 1 tc staff    0 Jul  4 13:20 File3
-rw-r--r-- 1 tc staff    0 Jul  4 13:20 File4
-rwxrwxr-x 1 tc staff 2927 Jul  4 13:19 WatchDirectory.shHere you see the script created a separate Dmesg directory for storing
all dmesg dumps plus the 4 files I created.

Here is the result in the Dmesg directory:

Code: [Select]

tc@E310:~/Scripting/WatchDirectory$ ls -l Dmesg/
total 336
-rw-r--r-- 1 tc staff 83270 Jul  4 13:20 File1-2026-07-04-13:20:00.Dmesg
-rw-r--r-- 1 tc staff 83270 Jul  4 13:20 File2-2026-07-04-13:20:05.Dmesg
-rw-r--r-- 1 tc staff 83270 Jul  4 13:20 File3-2026-07-04-13:20:10.Dmesg
-rw-r--r-- 1 tc staff 83270 Jul  4 13:20 File4-2026-07-04-13:20:15.Dmesg
The dmesg file names are in the form of:

Code: [Select]

CreatedFileName-TimeStamp.DmesgThat should simplify matching the dmesg to the core dump that triggered it.
Also, you'll notice a 5 second delay in the time stamps. I allow 5 seconds
between detecting the core dump and creating the dmesg file in case the
core dump needs time to finish writing.

As set up, the script monitors 1 directory, though it could monitor more.
It acts on file creation and ignores directory creation.
It will only monitor directories pointed to (no recursion).

The basic purpose of this script to monitor a directory and run commands
when a new file is created. It is fairly well commented. As such it should
be fairly simple to repurpose if anybody wishes to.

A copy is attached to the end of this post.