OK. I found an alternative timeout command written in Haskell. And insert "unblockSignals fullSignalSet" to it. Now "validate" can finish. I guess that one process (possibly GNU make) set signal mask and its children inherit it. What is a right solution for this? --Kazu

I confirmed that testsuite/timeout/install-inplace/bin/timeout.py does not receive SIGALRM, so it is waiting forever.

Any suggestions to fix this?

--Kazu

...

Hello,

The "validate" script against GHC HEAD freezes on FreeBSD 9.1. After sync-all, I did as follow:

---------------------------------------------------------------- % config_args="--with-iconv-includes=/usr/local/include --with-iconv-libraries=/usr/local/lib --with-gmp-includes=/usr/local/include --with-gmp-libraries=/usr/local/lib --with-gcc=/usr/local/bin/gcc47" CPUS=10 sh validate ----------------------------------------------------------------

This stopped quickly due to this problem: http://hackage.haskell.org/trac/ghc/ticket/7592

Then I executed "validate" with "--no-clean" again.

---------------------------------------------------------------- % config_args="--with-iconv-includes=/usr/local/include --with-iconv-libraries=/usr/local/lib --with-gmp-includes=/usr/local/include --with-gmp-libraries=/usr/local/lib --with-gcc=/usr/local/bin/gcc47" CPUS=10 sh validate --no-clean ----------------------------------------------------------------

GHC could be compiled and tests started. But this resulted in:

---------------------------------------------------------------- cd ../../libraries/base/tests && '/usr/home/kazu/work/ghc/bindisttest/install dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o qsemn001 qsemn001.hs >qsemn001.comp.stderr 2>&1 cd ../../libraries/base/tests && ./T5962 T5962.run.stdout 2>T5962.run.stderr cd ../../libraries/base/tests && ./5943 5943.run.stdout 2>5943.run.stderr cd ../../libraries/base/tests && ./T7034 T7034.run.stdout 2>T7034.run.stderr cd ../../libraries/base/tests && ./qsem001 qsem001.run.stdout 2>qsem001.run.stderr cd ../../libraries/base/tests && ./qsemn001 qsemn001.run.stdout 2>qsemn001.run.stderr

Wrong exit code (expected 0 , actual 9 ) Stdout:

Stderr:

*** unexpected failure for Chan002(normal) ----------------------------------------------------------------

And waiting for something forever.

Does anyone understand what happened?

Note that I can build GHC HEAD by typing "gmake" (v3.82 installed by the ports system) twice.

This is a serious problem for us since we want to merge our code to GHC HEAD. "validate" against GHC with our code on Linux and Mac passed so far. But "validate" against even vanilla GHC freezes.

P.S.

On FreeBSD, I applied the following patch for validate since unused-but-set-variable is not available.

diff --git a/mk/validate-settings.mk b/mk/validate-settings.mk index 399bf0e..378a3e6 100644 --- a/mk/validate-settings.mk +++ b/mk/validate-settings.mk @@ -13,7 +13,7 @@ HADDOCK_DOCS = YES # Debian doesn't turn -Werror=unused-but-set-variable on by default, so # we turn it on explicitly for consistency with other users ifeq "$(GccLT46)" "NO" -SRC_CC_WARNING_OPTS += -Werror=unused-but-set-variable +#SRC_CC_WARNING_OPTS += -Werror=unused-but-set-variable # gcc 4.6 gives 3 warning for giveCapabilityToTask not being inlined SRC_CC_WARNING_OPTS += -Wno-error=inline endif

--Kazu

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Hi, Even testsuite for GHC 7.4.2 ("gmake fast") freezes: * Consuming CPU 100% - compiling conc070.hs - 367_letnoes - throwto001 - Chan002 * Waiting for somting forever - signals004 I can reproduce this phenomena both for GHC HEAD and GHC 7.4.2 100%. --Kazu

Hi,

When I execute the following command (after GHC is build):

% THREADS=1 sh validate --testsuite-only

the following test command always freezes:

cd ./concurrent/should_run && '/usr/home/kazu/work/ghc/bindisttest/install dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history conc070.hs --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS conc070.interp.stdout 2>conc070.interp.stderr

The GHC command is consuming CPU 100%.

I tested this GHC 4.6/GHC 4.7 to make GHC and GNU make 3.81/3.82. But nothing changed.

Does nobody execute the "validate" script on FreeBSD before?

--Kazu

From: Kazu Yamamoto (山本和彦) Subject: Re: Validate of GHC HEAD freezes on FreeBSD

...

OK. I found an alternative timeout command written in Haskell. And insert "unblockSignals fullSignalSet" to it. Now "validate" can finish.

I guess that one process (possibly GNU make) set signal mask and its children inherit it. What is a right solution for this?

--Kazu

...

I confirmed that testsuite/timeout/install-inplace/bin/timeout.py does not receive SIGALRM, so it is waiting forever.

Any suggestions to fix this?

--Kazu

...

Hello,

The "validate" script against GHC HEAD freezes on FreeBSD 9.1. After sync-all, I did as follow:

---------------------------------------------------------------- % config_args="--with-iconv-includes=/usr/local/include --with-iconv-libraries=/usr/local/lib --with-gmp-includes=/usr/local/include --with-gmp-libraries=/usr/local/lib --with-gcc=/usr/local/bin/gcc47" CPUS=10 sh validate ----------------------------------------------------------------

This stopped quickly due to this problem: http://hackage.haskell.org/trac/ghc/ticket/7592

Then I executed "validate" with "--no-clean" again.

---------------------------------------------------------------- % config_args="--with-iconv-includes=/usr/local/include --with-iconv-libraries=/usr/local/lib --with-gmp-includes=/usr/local/include --with-gmp-libraries=/usr/local/lib --with-gcc=/usr/local/bin/gcc47" CPUS=10 sh validate --no-clean ----------------------------------------------------------------

GHC could be compiled and tests started. But this resulted in:

---------------------------------------------------------------- cd ../../libraries/base/tests && '/usr/home/kazu/work/ghc/bindisttest/install dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o qsemn001 qsemn001.hs >qsemn001.comp.stderr 2>&1 cd ../../libraries/base/tests && ./T5962 T5962.run.stdout 2>T5962.run.stderr cd ../../libraries/base/tests && ./5943 5943.run.stdout 2>5943.run.stderr cd ../../libraries/base/tests && ./T7034 T7034.run.stdout 2>T7034.run.stderr cd ../../libraries/base/tests && ./qsem001 qsem001.run.stdout 2>qsem001.run.stderr cd ../../libraries/base/tests && ./qsemn001 qsemn001.run.stdout 2>qsemn001.run.stderr

Wrong exit code (expected 0 , actual 9 ) Stdout:

Stderr:

*** unexpected failure for Chan002(normal) ----------------------------------------------------------------

And waiting for something forever.

Does anyone understand what happened?

Note that I can build GHC HEAD by typing "gmake" (v3.82 installed by the ports system) twice.

This is a serious problem for us since we want to merge our code to GHC HEAD. "validate" against GHC with our code on Linux and Mac passed so far. But "validate" against even vanilla GHC freezes.

P.S.

On FreeBSD, I applied the following patch for validate since unused-but-set-variable is not available.

diff --git a/mk/validate-settings.mk b/mk/validate-settings.mk index 399bf0e..378a3e6 100644 --- a/mk/validate-settings.mk +++ b/mk/validate-settings.mk @@ -13,7 +13,7 @@ HADDOCK_DOCS = YES # Debian doesn't turn -Werror=unused-but-set-variable on by default, so # we turn it on explicitly for consistency with other users ifeq "$(GccLT46)" "NO" -SRC_CC_WARNING_OPTS += -Werror=unused-but-set-variable +#SRC_CC_WARNING_OPTS += -Werror=unused-but-set-variable # gcc 4.6 gives 3 warning for giveCapabilityToTask not being inlined SRC_CC_WARNING_OPTS += -Wno-error=inline endif

--Kazu

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users