One stage2 compiler hanging around after head build (Solaris/x86 buildbot)
Hello, month or so ago I've noticed that one compiler instance is hanging around and spending 100% of CPU for nothing after a build of head (I'm not sure if it also happens on stable) on my Solaris/x86 buildbot. I've thought that it's my old ghc-6.8.2 from 2008/05/04 and so I've updated the compiler now to 6.8.3, but the hangup happens again and now I've noted that in fact it's the stage2 compiler: -bash-3.2$ ps -fU buildbot|grep 4380 buildbot 24480 27081 0 14:50:27 pts/6 0:00 grep 4380 buildbot 4380 641 25 12:38:14 ? 130:33 /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc -B/buildbot/ghc/kgar -bash-3.2$ my question is: is it just me who is affected by this or is it a well known issue in GHC build framework? Thanks, Karel
Hello, just verified that this also happens while building stable. Thanks! Karel Karel Gardas wrote:
Hello,
month or so ago I've noticed that one compiler instance is hanging around and spending 100% of CPU for nothing after a build of head (I'm not sure if it also happens on stable) on my Solaris/x86 buildbot. I've thought that it's my old ghc-6.8.2 from 2008/05/04 and so I've updated the compiler now to 6.8.3, but the hangup happens again and now I've noted that in fact it's the stage2 compiler:
-bash-3.2$ ps -fU buildbot|grep 4380 buildbot 24480 27081 0 14:50:27 pts/6 0:00 grep 4380 buildbot 4380 641 25 12:38:14 ? 130:33 /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc -B/buildbot/ghc/kgar -bash-3.2$
my question is: is it just me who is affected by this or is it a well known issue in GHC build framework?
Thanks, Karel
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
On Wed, Oct 01, 2008 at 02:56:26PM +0200, Karel Gardas wrote:
-bash-3.2$ ps -fU buildbot|grep 4380 buildbot 24480 27081 0 14:50:27 pts/6 0:00 grep 4380 buildbot 4380 641 25 12:38:14 ? 130:33 /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc -B/buildbot/ghc/kgar
my question is: is it just me who is affected by this or is it a well known issue in GHC build framework?
I don't see it. Can you find out the full commandline please? Thanks Ian
Ian Lynagh wrote:
On Wed, Oct 01, 2008 at 02:56:26PM +0200, Karel Gardas wrote:
-bash-3.2$ ps -fU buildbot|grep 4380 buildbot 24480 27081 0 14:50:27 pts/6 0:00 grep 4380 buildbot 4380 641 25 12:38:14 ? 130:33 /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc -B/buildbot/ghc/kgar
my question is: is it just me who is affected by this or is it a well known issue in GHC build framework?
I don't see it. Can you find out the full commandline please?
Does this help? # pargs 4380 4380: /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc -B/buildbot/ghc/kgar argv[0]: /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc argv[1]: -B/buildbot/ghc/kgardas/build/inplace-datadir/. argv[2]: -dynload argv[3]: wrapped argv[4]: --interactive argv[5]: -v0 argv[6]: -ignore-dot-ghci # Thanks, Karel
On Wed, Oct 01, 2008 at 08:57:17PM +0200, Karel Gardas wrote:
Does this help?
# pargs 4380 4380: /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc -B/buildbot/ghc/kgar argv[0]: /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc argv[1]: -B/buildbot/ghc/kgardas/build/inplace-datadir/. argv[2]: -dynload argv[3]: wrapped argv[4]: --interactive argv[5]: -v0 argv[6]: -ignore-dot-ghci #
Hmm, sounds like it's from one of the tests. Can you find out the working directory of the process? Or which files it has open, if any? Thanks Ian
Ian Lynagh wrote:
On Wed, Oct 01, 2008 at 08:57:17PM +0200, Karel Gardas wrote:
Does this help?
# pargs 4380 4380: /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc -B/buildbot/ghc/kgar argv[0]: /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc argv[1]: -B/buildbot/ghc/kgardas/build/inplace-datadir/. argv[2]: -dynload argv[3]: wrapped argv[4]: --interactive argv[5]: -v0 argv[6]: -ignore-dot-ghci #
Hmm, sounds like it's from one of the tests. Can you find out the working directory of the process? Or which files it has open, if any?
For this one it's no longer possible, since the dir went away when I've forced another head build. Here is the dir from the processes hanging from the last head build (its command line is the same): # pwdx 23414 23414: /export/zone/buildbot/root/buildbot/ghc/kgardas/build/testsuite/tests/ghc-regress/ghci/scripts # pargs 23414 23414: /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc -B/buildbot/ghc/kgar argv[0]: /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc argv[1]: -B/buildbot/ghc/kgardas/build/inplace-datadir/. argv[2]: -dynload argv[3]: wrapped argv[4]: --interactive argv[5]: -v0 argv[6]: -ignore-dot-ghci # Thanks, Karel
On Wed, Oct 01, 2008 at 09:16:12PM +0200, Karel Gardas wrote:
# pwdx 23414 23414: /export/zone/buildbot/root/buildbot/ghc/kgardas/build/testsuite/tests/ghc-regress/ghci/scripts
# pargs 23414 23414: /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc -B/buildbot/ghc/kgar argv[0]: /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc argv[1]: -B/buildbot/ghc/kgardas/build/inplace-datadir/. argv[2]: -dynload argv[3]: wrapped argv[4]: --interactive argv[5]: -v0 argv[6]: -ignore-dot-ghci #
Can you try to work out which test is causing the problem, please? e.g. in testsuite/tests/ghc-regress/ghci/scripts run make fast CLEANUP=1 TEST=ghci001 replacing "ghci001" with each of the first arguments to test in all.T. Or alternatively, remove stanzas in all.T using binary search and running make fast CLEANUP=1 until you narrow down which one causes the problem. Thanks Ian
participants (2)
-
Ian Lynagh -
Karel Gardas