I think I saw a duplicate somewhere - this is using real-time threads pinned to a single CPU but yield()ing in a spinning loop expecting to make progress.

(In reply to Richard Biener from comment #1)
> I think I saw a duplicate somewhere - this is using real-time threads pinned
> to a single CPU but yield()ing in a spinning loop expecting to make progress.

I checked the multilib issue, and couldn't see it.

Had a look on D's bugtracker, and found this related issue: https://issues.dlang.org/show_bug.cgi?id=18519

Raised a pull request against upstream phobos that fixes the test itself: https://github.com/dlang/phobos/pull/6824

Though I haven't yet checked running in dejagnu that the desirable behaviour transfers over well.

(In reply to Jakub Jelinek from comment #0)
> 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
> 

I couldn't reproduce, maybe I'm running the 32bit testsuite differently though?

Running ../../../../../libphobos/testsuite/libphobos.unittests/unittests.exp ...
WARNING: program timed out.
FAIL: libphobos.unittests/phobos/static/std.net.curl
WARNING: program timed out.
FAIL: libphobos.unittests/phobos/shared/std.net.curl


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

Patch I've sent upstream fixes this.

> 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

This would be a proc local to libphobos I guess?  There's nothing using this module outside of the libphobos testsuite.

(In reply to Iain Buclaw from comment #3)
> (In reply to Jakub Jelinek from comment #0)
> > 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
> > 
> 
> I couldn't reproduce, maybe I'm running the 32bit testsuite differently
> though?
> 
> Running ../../../../../libphobos/testsuite/libphobos.unittests/unittests.exp
> ...
> WARNING: program timed out.
> FAIL: libphobos.unittests/phobos/static/std.net.curl
> WARNING: program timed out.
> FAIL: libphobos.unittests/phobos/shared/std.net.curl

My i686-linux bootstraps are done through a couple of executable scripts in ~/hbin directory on x86_64-linux:
for i in ~/hbin/*; do echo ===$i===; cat $i; done
===/home/jakub/hbin/as===
#!/bin/sh
exec /usr/bin/as --32 "$@"
===/home/jakub/hbin/g++===
#!/bin/sh
exec /usr/bin/g++ -m32 "$@"
===/home/jakub/hbin/gcc===
#!/bin/sh
exec /usr/bin/gcc -m32 "$@"
===/home/jakub/hbin/ld===
#!/bin/sh
case "$*" in
  --version) cat <<\EOF
GNU ld version 2.20.52.0.1-10.fc17 20100131
Copyright 2012 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
EOF
  exit 0;;
esac
exec /usr/bin/ld -m elf_i386 -L /usr/lib/ "$@"

and then
PATH=~/hbin:$PATH i386 ../configure --enable-languages=default,obj-c++,lto,go,brig,d --enable-checking=yes,rtl,extra \
&& PATH=~/hbin:$PATH i386 make -j32 bootstrap > LOG 2>&1 \
&& PATH=~/hbin:$PATH i386 make -j32 -k check > LOGC 2>&1; \
../contrib/test_summary > LOGT 2>&1
and that got stuck forever if libcurl.i?86 wasn't installed (only libcurl.x86_64 and libcurl-devel.x86_64), but works
fine now that I also have libcurl.i?86 installed.

> > 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
> 
> This would be a proc local to libphobos I guess?  There's nothing using this
> module outside of the libphobos testsuite.

If the test doesn't fail if it fails to load libcurl (and doesn't get stuck), it is fine too.
If it fails if it is missing, yeah, something like a tcl procedure somewhere in libphobos/testsuite/lib/*.exp would do.
As libphobos itself doesn't need libcurl-devel, it is just dlopen, so I think you want to test that
#include <dlfcn.h>

int
main ()
{
  void *h = dlopen ("libcurl.so.4"); // etc., whatever the library will try to dlopen
  ...
}
will succeed dlopening it.

(In reply to Jakub Jelinek from comment #4)
> 
> If the test doesn't fail if it fails to load libcurl (and doesn't get
> stuck), it is fine too.
> If it fails if it is missing, yeah, something like a tcl procedure somewhere
> in libphobos/testsuite/lib/*.exp would do.
> As libphobos itself doesn't need libcurl-devel, it is just dlopen, so I
> think you want to test that
> #include <dlfcn.h>
> 
> int
> main ()
> {
>   void *h = dlopen ("libcurl.so.4"); // etc., whatever the library will try
> to dlopen
>   ...
> }
> will succeed dlopening it.


The names it will try before giving up:

---
version (OSX)
    static immutable names = ["libcurl.4.dylib"];
else version (Posix)
{
    static immutable names = ["libcurl.so", "libcurl.so.4",
    "libcurl-gnutls.so.4", "libcurl-nss.so.4", "libcurl.so.3"];
}
else version (Windows)
    static immutable names = ["libcurl.dll", "curl.dll"];
---

I think a link test would be good enough, as iff curl exists, but it has a different name to any of the above, then the std.net.curl module needs fixing.

(In reply to Jakub Jelinek from comment #4)
> 
> My i686-linux bootstraps are done through a couple of executable scripts in
> ~/hbin directory on x86_64-linux:
> for i in ~/hbin/*; do echo ===$i===; cat $i; done
> ===/home/jakub/hbin/as===
> #!/bin/sh
> exec /usr/bin/as --32 "$@"
> ===/home/jakub/hbin/g++===
> #!/bin/sh
> exec /usr/bin/g++ -m32 "$@"
> ===/home/jakub/hbin/gcc===
> #!/bin/sh
> exec /usr/bin/gcc -m32 "$@"
> ===/home/jakub/hbin/ld===
> #!/bin/sh
> case "$*" in
>   --version) cat <<\EOF
> GNU ld version 2.20.52.0.1-10.fc17 20100131
> Copyright 2012 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or (at your option) a later version.
> This program has absolutely no warranty.
> EOF
>   exit 0;;
> esac
> exec /usr/bin/ld -m elf_i386 -L /usr/lib/ "$@"
> 
> and then
> PATH=~/hbin:$PATH i386 ../configure
> --enable-languages=default,obj-c++,lto,go,brig,d
> --enable-checking=yes,rtl,extra \
> && PATH=~/hbin:$PATH i386 make -j32 bootstrap > LOG 2>&1 \
> && PATH=~/hbin:$PATH i386 make -j32 -k check > LOGC 2>&1; \
> ../contrib/test_summary > LOGT 2>&1
> and that got stuck forever if libcurl.i?86 wasn't installed (only
> libcurl.x86_64 and libcurl-devel.x86_64), but works
> fine now that I also have libcurl.i?86 installed.
> 

I can't say I followed this to the letter, but I could not reproduce.

RUNTESTFLAGS="unittests.exp" LIBRARY_PATH=/usr/lib32 PATH=~/hbin:$PATH \
  i386 make check -j8; \
  ../contrib/test_summary


Naturally, the libphobos testsuite took over 660 seconds to finish.  But still it eventually ended.

Going to deal with [2] and [3] anyway to prevent hitting the timeout in the first place anyway.

(In reply to Jakub Jelinek from comment #0)
> 
> 2) if Curl fails to initialize, the test shouldn't get stuck
> 

This part has been done in r268746.

Author: ibuclaw
Date: Wed Apr 24 14:17:34 2019
New Revision: 270545

URL: https://gcc.gnu.org/viewcvs?rev=270545&root=gcc&view=rev
Log:
libphobos: Skip curl tests if libcurl is not installed on the target.

libphobos/ChangeLog:

2019-04-24  Iain Buclaw  <ibuclaw@gdcproject.org>

	PR d/88654
	* testsuite/lib/libphobos.exp (libphobos-dg-test): Check
	libphobos_skipped_test_p before running test.
	(libphobos-dg-prune): New proc.
	(libphobos_init): Set libphobos_skip_tests.
	(libphobos_skipped_test_p): New proc.
	(check_effective_target_libcurl_available): New proc.
	* testsuite/libphobos.phobos/phobos.exp: Skip curl tests if library
	not found.
	* testsuite/libphobos.phobos_shared/phobos_shared.exp: Likewise.

Modified:
    trunk/libphobos/ChangeLog
    trunk/libphobos/testsuite/lib/libphobos.exp
    trunk/libphobos/testsuite/libphobos.phobos/phobos.exp
    trunk/libphobos/testsuite/libphobos.phobos_shared/phobos_shared.exp

(In reply to Jakub Jelinek from comment #0)
> 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

This has been done in r270545, nothing else left do here as far as I can see.