Apport self test FAIL: add_gdb_info() with SIGABRT/assert()

[Marco Rodrigues]

Reproduce using:
$ ./test/run

+ python -tt /usr/lib/python2.6/dist-packages/apport/report.py -v
add_gdb_info() with core dump file reference. ... ok
add_gdb_info() with SIGABRT/assert() ... readelf: Error: core: Failed to read file's magic number
FAIL
add_gdb_info() with inline core dump. ... ok
add_gdb_info() with a script. ... readelf: Error: /tmp/core: Failed to read file's magic number
FAIL
add_hooks_info(). ... ok
add_os_info(). ... ok
add_package_info(). ... ok
classification of $PATH. ... ok
add_proc_info(). ... ok
add_user_info(). ... ok
methods get along with binary data. ... ok
check_ignored() for system-wise blacklist. ... ok
_check_interpreted(). ... ok
crash_signature(). ... ok
_gen_stacktrace_top(). ... ok
has_useful_stacktrace(). ... ok
mark_ignore() and check_ignored(). ... ok
obsolete_packages(). ... ok
search_bug_patterns(). ... ok
standard_title(). ... ok

======================================================================
FAIL: add_gdb_info() with SIGABRT/assert()
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/apport/report.py", line 1536, in test_add_gdb_info_abort
    stdout=subprocess.PIPE) == 0
AssertionError

======================================================================
FAIL: add_gdb_info() with a script.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/apport/report.py", line 1497, in test_add_gdb_info_script
    stdout=subprocess.PIPE) == 0
AssertionError

----------------------------------------------------------------------
Ran 20 tests in 6.723s

FAILED (failures=2)

[Martin Pitt (pitti)]

Sometimes I get thisk, too, seems to be a race condition. In 9 cases out of 10 I don't get it, though. Is this constantly reproducible for you?

[Kees Cook (kees)]

Hm, I can only produce failures if I run two copies of test at the same time. It's using the current directory for writing the core file, so perhaps we can just move the tests to a private directory to fix it?

[Marco Rodrigues (gothicx)]

Yes, I can reproduce it everytime.

[Martin Pitt (pitti)]

so let's try running those in a temporary directory, although I don't see how the current scheme should break this (unless you run several in parallel). It's obviously a race condition somewhere, though.