[Bug d/88654] New: Hangs in libphobos testsuite

Wed Jan 2 08:54:00 GMT 2019

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88654

            Bug ID: 88654
           Summary: Hangs in libphobos testsuite
           Product: gcc
           Version: 9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: d
          Assignee: ibuclaw at gdcproject dot org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

I've reinstalled my workstation with Fedora 29 x86_64 recently, and since that
both my 32-bit bootstraps hanged in libphobos testing (while 64-bit ones were
ok).

In both cases, I saw a stuck process:
25678 pts/6    Sl+    0:00
/home/jakub/src/gcc/obj37/i686-pc-linux-gnu/libphobos/src/.libs/lt-unittest
std.net.curl
25679 pts/6    Z+     0:00 [cat] <defunct>
When I've tried to attach to it, one thread is waiting in pthread_join
#0  0xf7fc3049 in __kernel_vsyscall ()
#1  0xf2cf1aa6 in __pthread_timedjoin_ex () from /lib/libpthread.so.0
#2  0xf2cf1898 in pthread_join () from /lib/libpthread.so.0
#3  0xf2ea1004 in core.thread.Thread.join(bool) (rethrow=true, this=0xf29ef180)
at ../../../../libphobos/libdruntime/core/thread.d:776
#4  thread_joinAll () at ../../../../libphobos/libdruntime/core/thread.d:2369
#5  0xf2ebfa5c in rt_term () at
../../../../libphobos/libdruntime/rt/dmain2.d:215
#6  0xf2ebfac9 in runAll (this=0xffd5b97c) at
../../../../libphobos/libdruntime/rt/dmain2.d:490
#7  0xf2ebf6f1 in tryExec (this=0xffd5b97c, dg=...) at
../../../../libphobos/libdruntime/rt/dmain2.d:461
#8  0xf2ebf8ee in _d_run_main (argc=2, argv=0xffd5ba74, mainFunc=0x8049810 <D
main>) at ../../../../libphobos/libdruntime/rt/dmain2.d:494
#9  0x08049281 in main (argc=2, argv=0xffd5ba74) at
/home/jakub/src/gcc/libphobos/libdruntime/__entrypoint.di:44
#10 0xf2b34c09 in __libc_start_main () from /lib/libc.so.6
#11 0x08049326 in _start ()
while the other one is stuck in:
#0  0xf7fc3049 in __kernel_vsyscall ()
#1  0xf2cfaf11 in accept () from /lib/libpthread.so.0
#2  0xf7233398 in std.socket.Socket.accept() (this=0xf29f0010) at
../../../../libphobos/src/std/socket.d:2876
#3  0xf6b64e47 in std.net.curl.TestServer.loop(shared(std.socket.TcpSocket))
(listener=0xf29f0010) at ../../../../libphobos/src/std/net/curl.d:205
#4  0xf6b81daa in std.concurrency.exec (this=0xf29f0060) at
/home/jakub/src/gcc/libphobos/src/std/concurrency.d:506
#5  0xf2e9e547 in core.thread.Thread.run() (this=0xf29ef180) at
../../../../libphobos/libdruntime/core/thread.d:1469
#6  core.thread.Thread.run() (this=0xf29ef180) at
../../../../libphobos/libdruntime/core/thread.d:1461
#7  thread_entryPoint (arg=<optimized out>) at
../../../../libphobos/libdruntime/core/thread.d:400
#8  0xf2cf05de in start_thread () from /lib/libpthread.so.0
#9  0xf2c0697a in clone () from /lib/libc.so.6

When I try to run it by hand it showed a clue, but hanged anyway:
.libs/lt-unittest std.net.curl
****** FAIL release32 std.net.curl
std.net.curl.CurlException@../../../../libphobos/src/std/net/curl.d(4188):
Failed to load curl, tried "libcurl.so", "libcurl.so.4", "libcurl-gnutls.so.4",
"libcurl-nss.so.4", "libcurl.so.3".
----------------
/home/jakub/src/gcc/libphobos/src/std/exception.d:420 pure @safe void
std.exception.bailOut!(std.net.curl.CurlException).bailOut(immutable(char)[],
uint, const(char[])) [0xf6bb1f08]
/home/jakub/src/gcc/libphobos/src/std/exception.d:388 pure @safe bool
std.exception.enforce!(std.net.curl.CurlException, bool).enforce(bool, lazy
const(char)[], immutable(char)[], uint) [0xf6b737e5]
../../../../libphobos/src/std/net/curl.d:4188 void*
std.net.curl.CurlAPI.loadAPI() [0xf6b6bc40]
../../../../libphobos/src/std/net/curl.d:4135 __dgliteral1 [0xf6b6bab2]
/home/jakub/src/gcc/libphobos/src/std/concurrency.d:2422 __dgliteral2
[0xf6bdd299]
/home/jakub/src/gcc/libphobos/src/std/concurrency.d:2493 ref void*
std.concurrency.initOnce!(std.net.curl.CurlAPI._handle).initOnce(lazy void*,
core.sync.mutex.Mutex) [0xf6bdd212]
/home/jakub/src/gcc/libphobos/src/std/concurrency.d:2422 ref void*
std.concurrency.initOnce!(std.net.curl.CurlAPI._handle).initOnce(lazy void*)
[0xf6b73a1b]
../../../../libphobos/src/std/net/curl.d:4135 ref @property
std.net.curl.CurlAPI.API std.net.curl.CurlAPI.instance() [0xf6b6ba89]
../../../../libphobos/src/std/net/curl.d:4245 ref @property
std.net.curl.CurlAPI.API std.net.curl.Curl.curl() [0xf6b629d6]
../../../../libphobos/src/std/net/curl.d:4268 void
std.net.curl.Curl.initialize() [0xf6b64d95]
../../../../libphobos/src/std/net/curl.d:2547 void
std.net.curl.HTTP.initialize() [0xf6b6430f]
../../../../libphobos/src/std/net/curl.d:2520 std.net.curl.HTTP
std.net.curl.HTTP.opCall() [0xf6b5e8d2]
../../../../libphobos/src/std/net/curl.d:416 void
std.net.curl.download!(std.net.curl.AutoProtocol).download(const(char)[],
immutable(char)[], std.net.curl.AutoProtocol) [0xf6b6e764]
../../../../libphobos/src/std/net/curl.d:433 void
std.net.curl.__unittestL420_2() [0xf6b5e292]
/home/jakub/src/gcc/obj37/i686-pc-linux-gnu/libphobos/src/<no_file>:1 void
std.net.curl.__modtest() [0xf6b6d5d9]
../../../../libphobos/libdruntime/../testsuite/test_runner.d:58 void
test_runner.doTest(object.ModuleInfo*, ref bool) [0x80495eb]
../../../../libphobos/libdruntime/../testsuite/test_runner.d:30 bool
test_runner.testModules() [0x8049736]
../../../../libphobos/libdruntime/core/runtime.d:570 runModuleUnitTests
[0xf2e92b44]
../../../../libphobos/libdruntime/rt/dmain2.d:485 runAll [0xf2eb8aec]
../../../../libphobos/libdruntime/rt/dmain2.d:461 tryExec [0xf2eb86f0]
../../../../libphobos/libdruntime/rt/dmain2.d:494 _d_run_main [0xf2eb88ed]
/home/jakub/src/gcc/libphobos/libdruntime/__entrypoint.di:44 main [0x8049280]
??:? __libc_start_main [0xf2b2ec08]
??:? _start [0x8049325]
??:? ???[0xffffffff]

Indeed, I had just 64-bit libcurl.so.4 installed, not 32-bit libcurl.so.4 and
installing the latter makes the command run from the command line succeed.

The reason I'm filing this is that there are multiple issues:

1) what I'm worried about most is that the timeouts for tests don't work, it
happens that some test gets stuck, but it should be killed after 5 minutes or
for how long the default timeout is set and the set should FAIL in that case or
something similar

2) if Curl fails to initialize, the test shouldn't get stuck

3) and, if libcurl isn't available, I think it would be better to skip the test
as UNSUPPORTED, i.e. add some effective-target that tests if libcurl is
available and if it fails, don't even try to run the test