strongswan fails to build in xenial on amd64 (test timeouts)

Bug #1592706 reported by Matthias Klose on 2016-06-15
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
strongswan (Ubuntu)
High
Unassigned

Bug Description

see https://launchpad.net/ubuntu/+archive/test-rebuild-20160614/+build/10003200
using ppa:ubuntu-toolchain-r/ppa

  Passed all 4 'watcher' test cases
  Running suite 'stream':
    Running case 'sync': +++
    Running case 'async': +++
    Running case 'all': +++
    Running case 'concurrency': +
Session terminated, terminating shell...make[6]: *** wait: No child processes. Stop.
make[6]: *** Waiting for unfinished jobs....
make[6]: *** wait: No child processes. Stop.
make[8]: *** [check-TESTS] Terminated
 ...terminated.
make[5]: *** [check] Error 2
make[4]: *** [check-recursive] Terminated
make: *** [build] Terminated
Makefile:1347: recipe for target 'check-TESTS' failed
Makefile:2109: recipe for target 'check' failed
Makefile:515: recipe for target 'check-recursive' failed
debian/rules:262: recipe for target 'build' failed
Makefile:576: recipe for target 'check-recursive' failed
make[3]: *** [check-recursive] Terminated
make[7]: *** wait: No child processes. Stop.
make[7]: *** Waiting for unfinished jobs....
make[7]: *** wait: No child processes. Stop.
Makefile:865: recipe for target 'check' failed
make[2]: *** [check] Terminated
debian/rules:258: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Terminated
Build killed with signal TERM after 150 minutes of inactivity

Matthias Klose (doko) wrote :

several retries always show the same error. Can't reproduce locally in a fresh chroot using the following configurations:

 - xenial-release
 - xenial-release + -updates + -security
 - xenial-release + ppa:ubuntu-toolchain-r/ppa
 - xenial-release + -updates + -security + ppa:ubuntu-toolchain-r/ppa

unrelated to any toolchain updates.

I've seen this in some Travis CI runs of our test suite. There occasionally seems to be a lockup (not sure if it is an actual deadlock). But I was never able to reproduce it. Is it possible to get a backtrace when the test hangs and gets killed by the builder? Or logon to the build host and attach gdb to the test runner while it hangs? Or get access to a build host to reproduce the issue?

Download full text (4.4 KiB)

Just hit that today.

FYI
#0 0x00007f22d25008a8 in __pthread_mutex_cond_lock_full (mutex=0xca) at ../nptl/pthread_mutex_lock.c:409
#1 0x00007f22d2747970 in ?? ()
#2 0x0000564037d2bae0 in frame_dummy ()
#3 0x0000564037d2bb7d in test_runner_init (init=init@entry=false) at tests.c:55
#4 0x0000564037d6e340 in post_test (init=0x564037d2bae0 <test_runner_init>, init@entry=0x564038cdcdd0, check_leaks=check_leaks@entry=false,
    failures=failures@entry=0x564038c160e0, name=<optimized out>, i=i@entry=1, leaks=leaks@entry=0x7ffe92cb780c) at test_runner.c:350
#5 0x0000564037d6eada in run_case (cfg=0x0, init=0x564038cdcdd0, tcase=0x564038c80470) at test_runner.c:461
#6 run_suite (cfg=0x0, init=0x564038cdcdd0, suite=0x564038cdd860) at test_runner.c:520
#7 test_runner_run (name=0x564037d6f1cd "libstrongswan", configs=<optimized out>, init=0x564038cdcdd0) at test_runner.c:580
#8 0x00007f22d214d3f1 in add_derivation (nsteps=<optimized out>, handle=<optimized out>,
    toset=0xbceb08488b48308b <error: Cannot access memory at address 0xbceb08488b48308b>,
    fromset=0xc672cb394818758b <error: Cannot access memory at address 0xc672cb394818758b>) at gconv_db.c:165
#9 find_derivation (toset=<optimized out>, toset_expand=<optimized out>, fromset=<optimized out>, fromset_expand=<optimized out>, handle=<optimized out>,
    nsteps=<optimized out>) at gconv_db.c:696
#10 0xddf6258d4c544155 in ?? ()
#11 0xddf62d8d48550021 in ?? ()
#12 0x8949f68949530021 in ?? ()
#13 0x08ec8348e5294cd5 in ?? ()
#14 0xfbc107e803fdc148 in ?? ()
#15 0xdb312074ed8548ff in ?? ()
#16 0x0000000000841f0f in ?? ()
#17 0x8944f6894cea894c in ?? ()
#18 0xc38348dc14ff41ff in ?? ()
#19 0x8348ea75dd394801 in ?? ()
#20 0x5d415c415d5b08c4 in ?? ()
#21 0x2e6690c35f415e41 in ?? ()
#22 0x0000000000841f0f in ?? ()
#23 0x08ec83480000c3f3 in ?? ()
#24 0x000000c308c48348 in ?? ()
#25 0x5453455400020001 in ?? ()
#26 0x4e4947554c505f53 in ?? ()
#27 0x2e73747365740053 in ?? ()
#28 0x7365740064616f6c in ?? ()
#29 0x6967756c702e7374 in ?? ()
#30 0x62696c007269646e in ?? ()
#31 0x7773676e6f727473 in ?? ()
#32 0x3a70747468006e61 in ?? ()
#33 0x0000000000002f2f in ?? ()
#34 0x6365762d74736574 in ?? ()
#35 0x626e752073726f74 in ?? ()
#36 0x61646c20646e756f in ?? ()
#37 0x313173636b702070 in ?? ()
---Type <return> to continue, or q <return> to quit---
#38 0x6120696e73656120 in ?? ()
#39 0x7320326372207365 in ?? ()
#40 0x3161687320326168 in ?? ()
#41 0x35646d2034646d20 in ?? ()
#42 0x6472203166676d20 in ?? ()
#43 0x6e617220646e6172 in ?? ()
#44 0x636e6f6e206d6f64 in ?? ()
#45 0x7220393035782065 in ?? ()
#46 0x6f697461636f7665 in ?? ()
#47 0x7274736e6f63206e in ?? ()
#48 0x63612073746e6961 in ?? ()
#49 0x6b62757020747265 in ?? ()
#50 0x3173636b70207965 in ?? ()
#51 0x70203773636b7020 in ?? ()
#52 0x636b70203873636b in ?? ()
#53 0x2070677020323173 in ?? ()
#54 0x732079656b736e64 in ?? ()
#55 0x65702079656b6873 in ?? ()
#56 0x73736e65706f206d in ?? ()
#57 0x747079726367206c in ?? ()
#58 0x20676c612d666120 in ?? ()
#59 0x6672702d73706966 in ?? ()
#60 0x65676120706d6720 in ?? ()
#61 0x6f7061686320746e in ?? ()
#62 0x206362637820796c in ?? ()
#63 0x616d682063616d63 in ?? ()
#64 0x6363207274632063 in ?? ()
#65 0x7...

Read more...

It still hangs on my laptop, but in a schroot so harder than usual to debug.
I'll keep it til tomorrow morning, if you let me know anything else I should check there let me know.

We didn't follow up on this unfortunately but latter builds in other releases as well as xenial work fine.

For example:
https://launchpad.net/ubuntu/+source/strongswan/5.3.5-1ubuntu3.3

Changed in strongswan (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers