apport-retrace creates a duplicate Stacktrace if the output file already exists

[Brian Murray]

Using the following command:

PYTHONPATH=$PYTHONPATH:~/source-trees/apport/trunk python3 ~/source-trees/apport/trunk/bin/apport-retrace -S ~/source-trees/daisy/trunk/retracer/config --sandbox-dir /mnt/sec-machines/apport-retrace -C /mnt/sec-machines/apport-retrace /tmp/_lib_systemd_systemd-udevd.0.crash -o /tmp/retraced-systemd.crash

If I run that two times in a row the Stacktrace, in the output file, ends up having duplicate information in it. For example:

Stacktrace:
 #0 0xb6d6b116 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81
 No locals.
 #1 0xb6ef1e88 in sd_event_wait (e=0xb8b0a5b0, timeout=<optimized out>) at ../src/libsystemd/sd-event/sd-event.c:2490
         ev_queue = 0xbee06688
         ev_queue_max = 9
         r = <optimized out>
         m = <optimized out>
         i = <optimized out>
         __PRETTY_FUNCTION__ = "sd_event_wait"
 #2 0xb6f00658 in sd_event_run (timeout=18446744073709551615, e=0xb8b0a5b0) at ../src/libsystemd/sd-event/sd-event.c:2621
         r = <optimized out>
 #3 sd_event_loop (e=0xb8b0a5b0) at ../src/libsystemd/sd-event/sd-event.c:2645
         r = <optimized out>
         __PRETTY_FUNCTION__ = "sd_event_loop"
 #4 0xb6edf7b6 in run (cgroup=<optimized out>, fd_uevent=<optimized out>, fd_ctrl=<optimized out>) at ../src/udev/udevd.c:1626
         manager = 0x0
         r = 0
 #5 main (argc=<optimized out>, argv=<optimized out>) at ../src/udev/udevd.c:1749
         cgroup = 0xb8afa170 "/lxc/t/system.slice/systemd-udevd.service"
         r = <optimized out>
         fd_uevent = <optimized out>
         __func__ = "main"
 $7 = -99Found 0 new threads in iteration 0.
 .

 Thread 1 (Thread 0xb6ecb000 (LWP 5641)):
 #0 0xb6d6b116 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81
 No locals.
 #1 0xb6ef1e88 in sd_event_wait (e=0xb8b0a5b0, timeout=<optimized out>) at ../src/libsystemd/sd-event/sd-event.c:2490
         ev_queue = 0xbee06688
         ev_queue_max = 9
         r = <optimized out>
         m = <optimized out>
         i = <optimized out>
         __PRETTY_FUNCTION__ = "sd_event_wait"
 #2 0xb6f00658 in sd_event_run (timeout=18446744073709551615, e=0xb8b0a5b0) at ../src/libsystemd/sd-event/sd-event.c:2621
         r = <optimized out>
 #3 sd_event_loop (e=0xb8b0a5b0) at ../src/libsystemd/sd-event/sd-event.c:2645
         r = <optimized out>
         __PRETTY_FUNCTION__ = "sd_event_loop"
 #4 0xb6edf7b6 in run (cgroup=<optimized out>, fd_uevent=<optimized out>, fd_ctrl=<optimized out>) at ../src/udev/udevd.c:1626
         manager = 0x0
         r = 0
 #5 main (argc=<optimized out>, argv=<optimized out>) at ../src/udev/udevd.c:1749
         cgroup = 0xb8afa170 "/lxc/t/system.slice/systemd-udevd.service"
         r = <optimized out>
         fd_uevent = <optimized out>
         __func__ = "main"

This also ends up creating a strange SAS:

StacktraceAddressSignature: /lib/systemd/systemd-udevd:11:/lib/arm-linux-gnueabihf/libc-2.21.so+94116:/lib/systemd/systemd-udevd+19e88:/lib/systemd/systemd-udevd+28658:/lib/systemd/systemd-udevd+77b6:/lib/arm-linux-gnueabihf/libc-2.21.so+94116:/lib/systemd/systemd-udevd+19e88:/lib/systemd/systemd-udevd+28658:/lib/systemd/systemd-udevd+77b6

This was observed with apport revision 3023.

[Brian Murray (brian-murray)]

Attached is the original crash report which I was retracing.