Wind River Support Network

Description

When an application using the itimer functions crashes, if the timer expires as the core file is being written then the file will be truncated.

Steps to Reproduce

$ configure --enable-board=XXX --enable-rootfs=glibc_std --enable-kernel=standard
$ make
$ make export-sdk

Using the SDK, build the following test code:

--8<--
#include <stdio.h>
#include <stdlib.h>
#include <sys/time.h>
#include <unistd.h>

int main()
{
        char *buf;
        int size = 1024 * 1024;
        int i;
        struct itimerval it = {{0,}};

        buf = malloc(size);
        for (i = 0; i < size / getpagesize(); i++)
                buf[i * getpagesize()] = 0x1;

        it.it_value.tv_sec = 0;
        it.it_value.tv_usec = 100;
        setitimer(ITIMER_REAL, &it, NULL);

        buf = NULL;
        *buf = 0xde;

        return 0;
}
--8<--

usiing: $CC $CFLAGS -g -o test test.c

Also create the following coredumper.sh script file:

--8<--
#!/bin/sh
cat > /coredump
--8<--

This is a simplified version of what the customer uses as his script also records other information about the process, but this simplified version is enough.

Copy the files to the rootfs of the target and boot the target.

Log in and run the following commands:

  # ulimit -c unlimited
  # echo "|/coredumper.sh" > /proc/sys/kernel/core_pattern
  # echo 1 > /proc/sys/kernel/core_pipe_limit

Now run the test application:

  # ./test-ppc
  Segmentation fault (core dumped)

The core file may actually not exist, or may be quite small as in is example:

  # ls -l /core*
  total 72
  -rw-r--r-- 1 root root 65536 Jul 24  2013 coredump
  -rwxr-xr-x 1 root root    31 Jul 24  2013 coredumper.sh

Loading this core file into gdb indicates that it is truncated.

Rerun the test but with the call to setitimer() commented out in the test code, you will see that the core file is much longer:

  -rw-r--r-- 1 root root 1298432 Jul 24 2013 coredump

This file loaded into gdb works fine.

Note that in some cases the core file is the correct size also if the file is written directly as per the more normal use case, but this seems to be target dependent. Using the piped core seems to reproduce the problem every time.