Re: Strace
Thanks Simon! Yup I'll mark them when I get home. It had occurred to me today that the difference might be in that ghc-pkg on windows uses locks and on Linux atomic replace. Not sure why the same wasn't done on Windows but that might be it. I'll mark them tomorrow :) Cheers, Tamar On Tue, Jun 26, 2018, 09:59 Simon Peyton Jones wrote: > Great. https://ghc.haskell.org/trac/ghc/ticket/15313#ticket is created. > > > > I don’t know how to force them to be “cpu multirace on windows”. If you > could do that sometime it’d be great. No rush. Thank you! > > > Simon > > > > *From:* Phyx > *Sent:* 26 June 2018 06:01 > *To:* Simon Peyton Jones > *Subject:* Re: Strace > > > > Hi Simon, > > > > Thanks for the log, that does give a clue. The command fails with > > > > setup.exe: 'C:/code/HEAD/inplace/bin/ghc-pkg.exe' exited with an error: > ... > rule-defining-plugin-0.1: cannot find any of > > ["libHSrule-defining-plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z.a","libHSrule-defining-plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z.p_a"," > libHSrule-defining-plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z-ghc8.5.20180616.so > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2FlibHSrule-defining-plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z-ghc8.5.20180616.so&data=02%7C01%7Csimonpj%40microsoft.com%7C8583db4eca874993ceee08d5db21e587%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636655860987246561&sdata=1DZ1OEllqBTNwnAjzL5JQMyfchbhE7x7VgUYJZeJdZ4%3D&reserved=0> > ","libHSrule-defining-plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z-ghc8.5.20180616.dylib","HSrule-defining-plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z-ghc8.5.20180616.dll"] > on library path (use --force to override) > > make[2]: *** [Makefile:18: package.T10420] Error 1 > > > > so it's the `setup install` from > https://github.com/ghc/ghc/blob/c2783ccf545faabd21a234a4dfc569cd856082b9/testsuite/tests/plugins/rule-defining-plugin/Makefile > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc%2Fghc%2Fblob%2Fc2783ccf545faabd21a234a4dfc569cd856082b9%2Ftestsuite%2Ftests%2Fplugins%2Frule-defining-plugin%2FMakefile&data=02%7C01%7Csimonpj%40microsoft.com%7C8583db4eca874993ceee08d5db21e587%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636655860987256565&sdata=3sO%2FDU5dhjiZ3au%2BbsWghcRA%2FZIwT1vj2iuJaMiqufU%3D&reserved=0> > failing. > > > > unfortunately, all those tests run with -v0 which is annoying because now > the verbosity of the testsuite doesn't control that of these tests. I'm not > sure why these commands fail under heavy load though. > > I'll need to dive into the source of ghc-pkg to figure out what's > happening. Notice that all the framework failures are these plugin tests > which modify a package database. A wild guess is that ghc-pkg tries > > to take a lock on all package-databases or something when it's mutating > one. But I'm not intimately familiar with the package store and this > doesn't explain why it doesn't happen on Linux. > > > > for now one solution I can propose is to create a ticket to track these > and mark these tests as cpu multirace on Windows, which will force them to > run sequentially. I'll try to take a look at ghc-pkg this week > > and if I don't figure anything out I'll force the tests sequential on the > short term. > > > > Cheers, > > Tamar > > > > > > On Mon, Jun 25, 2018 at 4:08 AM, Simon Peyton Jones > wrote: > > Tamar > > I tried this > > TEST_VERBOSITY="VERBOSE=3" sh validate --fast --no-clean >& log > > in the root directory. I get the framework failures, but I’m not sure the > verbosity-control worked. > > Log attached > > SImon > > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Strace
Great. https://ghc.haskell.org/trac/ghc/ticket/15313#ticket is created. I don’t know how to force them to be “cpu multirace on windows”. If you could do that sometime it’d be great. No rush. Thank you! Simon From: Phyx Sent: 26 June 2018 06:01 To: Simon Peyton Jones Subject: Re: Strace Hi Simon, Thanks for the log, that does give a clue. The command fails with setup.exe: 'C:/code/HEAD/inplace/bin/ghc-pkg.exe' exited with an error: ... rule-defining-plugin-0.1: cannot find any of ["libHSrule-defining-plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z.a","libHSrule-defining-plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z.p_a","libHSrule-defining-plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z-ghc8.5.20180616.so<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2FlibHSrule-defining-plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z-ghc8.5.20180616.so&data=02%7C01%7Csimonpj%40microsoft.com%7C8583db4eca874993ceee08d5db21e587%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636655860987246561&sdata=1DZ1OEllqBTNwnAjzL5JQMyfchbhE7x7VgUYJZeJdZ4%3D&reserved=0>","libHSrule-defining-plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z-ghc8.5.20180616.dylib","HSrule-defining-plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z-ghc8.5.20180616.dll"] on library path (use --force to override) make[2]: *** [Makefile:18: package.T10420] Error 1 so it's the `setup install` from https://github.com/ghc/ghc/blob/c2783ccf545faabd21a234a4dfc569cd856082b9/testsuite/tests/plugins/rule-defining-plugin/Makefile<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc%2Fghc%2Fblob%2Fc2783ccf545faabd21a234a4dfc569cd856082b9%2Ftestsuite%2Ftests%2Fplugins%2Frule-defining-plugin%2FMakefile&data=02%7C01%7Csimonpj%40microsoft.com%7C8583db4eca874993ceee08d5db21e587%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636655860987256565&sdata=3sO%2FDU5dhjiZ3au%2BbsWghcRA%2FZIwT1vj2iuJaMiqufU%3D&reserved=0> failing. unfortunately, all those tests run with -v0 which is annoying because now the verbosity of the testsuite doesn't control that of these tests. I'm not sure why these commands fail under heavy load though. I'll need to dive into the source of ghc-pkg to figure out what's happening. Notice that all the framework failures are these plugin tests which modify a package database. A wild guess is that ghc-pkg tries to take a lock on all package-databases or something when it's mutating one. But I'm not intimately familiar with the package store and this doesn't explain why it doesn't happen on Linux. for now one solution I can propose is to create a ticket to track these and mark these tests as cpu multirace on Windows, which will force them to run sequentially. I'll try to take a look at ghc-pkg this week and if I don't figure anything out I'll force the tests sequential on the short term. Cheers, Tamar On Mon, Jun 25, 2018 at 4:08 AM, Simon Peyton Jones mailto:simo...@microsoft.com>> wrote: Tamar I tried this TEST_VERBOSITY="VERBOSE=3" sh validate --fast --no-clean >& log in the root directory. I get the framework failures, but I’m not sure the verbosity-control worked. Log attached SImon ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Strace
TOP=/c/code/HEAD/testsuite* > > *cd "./plugins12.run" && $MAKE -s --no-print-directory plugins12 * > > *=> plugins13(normal) 13 of 25 [0, 2, 0]* > > *cd "./plugins13.run" && $MAKE -s --no-print-directory -C simple-plugin > package.plugins13 TOP=/c/code/HEAD/testsuite* > > *cd "./plugins13.run" && $MAKE -s --no-print-directory plugins13 * > > *=> plugins14(normal) 14 of 25 [0, 2, 0]* > > *cd "./plugins14.run" && $MAKE -s --no-print-directory -C simple-plugin > package.plugins14 TOP=/c/code/HEAD/testsuite* > > *cd "./plugins14.run" && $MAKE -s --no-print-directory plugins14 * > > *=> plugins15(normal) 15 of 25 [0, 2, 0]* > > *cd "./plugins15.run" && $MAKE -s --no-print-directory -C simple-plugin > package.plugins15 TOP=/c/code/HEAD/testsuite* > > *cd "./plugins15.run" && $MAKE -s --no-print-directory plugins15 * > > *=> T10420(normal) 16 of 25 [0, 2, 0]* > > *cd "./T10420.run" && $MAKE -s --no-print-directory -C > rule-defining-plugin package.T10420 TOP=/c/code/HEAD/testsuite* > > *cd "./T10420.run" && $MAKE -s --no-print-directory T10420 * > > *=> T10294(normal) 17 of 25 [0, 2, 0]* > > *cd "./T10294.run" && $MAKE -s --no-print-directory -C annotation-plugin > package.T10294 TOP=/c/code/HEAD/testsuite* > > *cd "./T10294.run" && $MAKE -s --no-print-directory T10294 * > > *=> T10294a(normal) 18 of 25 [0, 2, 0]* > > *cd "./T10294a.run" && $MAKE -s --no-print-directory -C annotation-plugin > package.T10294a TOP=/c/code/HEAD/testsuite* > > *cd "./T10294a.run" && $MAKE -s --no-print-directory T10294a * > > *=> frontend01(normal) 19 of 25 [0, 2, 0]* > > *cd "./frontend01.run" && $MAKE -s --no-print-directory frontend01 * > > *=> T11244(normal) 20 of 25 [0, 2, 0]* > > *cd "./T11244.run" && $MAKE -s --no-print-directory -C > rule-defining-plugin package.T11244 TOP=/c/code/HEAD/testsuite* > > *cd "./T11244.run" && $MAKE -s --no-print-directory T11244 * > > *Actual stderr output differs from expected:* > > *diff -uw "./T11244.run/T11244.stderr.normalised" > "./T11244.run/T11244.run.stderr.normalised"* > > unexpected failure for T11244(normal)* > > *=> T12567a(normal) 21 of 25 [0, 3, 0]* > > *cd "./T12567a.run" && $MAKE -s --no-print-directory -C simple-plugin > package.T12567a TOP=/c/code/HEAD/testsuite* > > *cd "./T12567a.run" && $MAKE -s --no-print-directory T12567a * > > *=> T14335(normal) 22 of 25 [0, 3, 0]* > > *cd "./T14335.run" && $MAKE -s --no-print-directory -C simple-plugin > package.plugins01 TOP=/c/code/HEAD/testsuite* > > *cd "./T14335.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c > T14335.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output > -package-db simple-plugin/pkg.plugins01/local.package.conf -fplugin > Simple.Plugin-fexternal-interpreter -package simple-plugin -static* > > *=> plugin-recomp-pure(normal) 23 of 25 [0, 3, 0]* > > *cd "./plugin-recomp-pure.run" && $MAKE -s --no-print-directory -C > plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite* > > *cd "./plugin-recomp-pure.run" && $MAKE -s --no-print-directory > plugin-recomp-pure * > > *=> plugin-recomp-impure(normal) 24 of 25 [0, 3, 0]* > > *cd "./plugin-recomp-impure.run" && $MAKE -s --no-print-directory -C > plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite* > > *cd "./plugin-recomp-impure.run" && $MAKE -s --no-print-directory > plugin-recomp-impure * > > *=> plugin-recomp-flags(normal) 25 of 25 [0, 3, 0]* > > *cd "./plugin-recomp-flags.run" && $MAKE -s --no-print-directory -C > plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite* > > *cd "./plugin-recomp-flags.run" && $MAKE -s --no-print-directory > plugin-recomp-flags * > > > > *Unexpected results from:* > > *TEST="T11244 plugins09 plugins11"* > > > > *SUMMARY for test run started at Mon Jun 18 11:24:57 2018 GMTST* > > *0:11:18 spent to go through* > > * 25 total tests, which gave rise to* > > * 35 test cases, of which* > > * 11 were s
RE: Strace
E -s --no-print-directory -C rule-defining-plugin package.T11244 TOP=/c/code/HEAD/testsuite cd "./T11244.run" && $MAKE -s --no-print-directory T11244 Actual stderr output differs from expected: diff -uw "./T11244.run/T11244.stderr.normalised" "./T11244.run/T11244.run.stderr.normalised" *** unexpected failure for T11244(normal) => T12567a(normal) 21 of 25 [0, 3, 0] cd "./T12567a.run" && $MAKE -s --no-print-directory -C simple-plugin package.T12567a TOP=/c/code/HEAD/testsuite cd "./T12567a.run" && $MAKE -s --no-print-directory T12567a => T14335(normal) 22 of 25 [0, 3, 0] cd "./T14335.run" && $MAKE -s --no-print-directory -C simple-plugin package.plugins01 TOP=/c/code/HEAD/testsuite cd "./T14335.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c T14335.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -package-db simple-plugin/pkg.plugins01/local.package.conf -fplugin Simple.Plugin-fexternal-interpreter -package simple-plugin -static => plugin-recomp-pure(normal) 23 of 25 [0, 3, 0] cd "./plugin-recomp-pure.run" && $MAKE -s --no-print-directory -C plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite cd "./plugin-recomp-pure.run" && $MAKE -s --no-print-directory plugin-recomp-pure => plugin-recomp-impure(normal) 24 of 25 [0, 3, 0] cd "./plugin-recomp-impure.run" && $MAKE -s --no-print-directory -C plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite cd "./plugin-recomp-impure.run" && $MAKE -s --no-print-directory plugin-recomp-impure => plugin-recomp-flags(normal) 25 of 25 [0, 3, 0] cd "./plugin-recomp-flags.run" && $MAKE -s --no-print-directory -C plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite cd "./plugin-recomp-flags.run" && $MAKE -s --no-print-directory plugin-recomp-flags Unexpected results from: TEST="T11244 plugins09 plugins11" SUMMARY for test run started at Mon Jun 18 11:24:57 2018 GMTST 0:11:18 spent to go through 25 total tests, which gave rise to 35 test cases, of which 11 were skipped 0 had missing libraries 19 expected passes 2 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 3 unexpected failures 0 unexpected stat failures Unexpected failures: plugins09.run plugins09 [bad stdout] (normal) plugins11.run plugins11 [bad stdout] (normal) T11244.run T11244 [bad stderr] (normal) make: *** [../../mk/test.mk:329: test] Error 1 .../tests/plugins$ From: Phyx Sent: 13 June 2018 20:47 To: Simon Peyton Jones Cc: ghc-devs@haskell.org Subject: Re: Strace Hi Simon, On Wed, Jun 13, 2018 at 5:24 PM, Simon Peyton Jones mailto:simo...@microsoft.com>> wrote: OK – so maybe the root cause is a framework failure – and indeed for the last few weeks I’ve seen Framework failures: plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) plugins/T10420.run T10420 [normal] (pre_cmd failed: 2) plugins/T11244.run T11244 [normal] (pre_cmd failed: 2) I have just learned to live with these failures, because I knew you were working on making things better. But it sounds as if they are still taking place. The commit I made should have reduced the amount of failing tests to 0. framework failures are always quite unusual. So: * Yes, please make it not happen by default I've removed the code, if you update it should be gone. It was there and on by default because I was trying to debug failures on Harbormaster, I realized a switch isn't very useful as I won't be able to toggle it for Harbormaster anyway. * * If you don’t get these framework failures, can we work together to resolve them? These don't happen for me nor on Harbormaster, try picking a test, e.g T10420 run only that test to make sure it's not a threading issue: make TEST=T10420 test -C testsuite/tests If it still gives a framework error then do at the top level make VERBOSE=3 TEST=T10420 test -C testsuite/tests once it runs, the output should contain the command it ran as a pre_cmd, and the stdout and stderr from the pre_cmd output. Could you then send the error? if it doesn't show any of this, try make CLEANP=0 VERBOSE=3 TEST= T10420 test -C testsuite/tests --trace and copy and paste the pre_cmd command, which should just replay the action it did. Cheers, Tamar Thanks Simon From: Phyx mailto:loneti...@gmail.com>> Sent: 13 June 2018 17:19 To: Simon Peyton Jones mailto:simo...@microsoft.com>> Cc: ghc-devs@haskell.org<mailt
RE: Strace
I've removed the code, if you update it should be gone Yes, that’s great. The commit I made should have reduced the amount of failing tests to 0. framework failures are always quite unusual. Definitely not zero! I’m getting these failing tests Unexpected failures: plugins/plugins07.runplugins07 [bad exit code] (normal) plugins/plugins09.runplugins09 [bad stdout] (normal) plugins/plugins11.runplugins11 [bad stdout] (normal) plugins/T10420.run T10420 [bad exit code] (normal) plugins/T11244.run T11244 [bad stderr] (normal) plugins/plugin-recomp-pure.run plugin-recomp-pure [bad exit code] (normal) plugins/plugin-recomp-impure.run plugin-recomp-impure [bad exit code] (normal) plugins/plugin-recomp-flags.run plugin-recomp-flags [bad exit code] (normal) rts/stack002.run stack002 [exit code non-0] (normal) rts/T3236.runT3236 [exit code non-0] (normal) rts/testwsdeque.run testwsdeque [exit code non-0] (threaded1) /../libraries/Win32/tests/T4452.run T4452 [bad exit code] (normal) Unexpected stat failures: perf/compiler/T6048.run T6048 [stat not good enough] (optasm) perf/compiler/T12234.run T12234 [stat not good enough] (optasm) perf/compiler/T12150.run T12150 [stat not good enough] (optasm) perf/should_run/T15226.run T15226 [stat too good] (normal) perf/should_run/T15226a.run T15226a [stat too good] (normal) perf/compiler/MultiLayerModules.run MultiLayerModules [stat not good enough] (normal) Framework failures: plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) plugins/T10420.runT10420 [normal] (pre_cmd failed: 2) plugins/T11244.runT11244 [normal] (pre_cmd failed: 2) plugins/plugin-recomp-pure.runplugin-recomp-pure [normal] (pre_cmd failed: 2) plugins/plugin-recomp-impure.run plugin-recomp-impure [normal] (pre_cmd failed: 2) plugins/plugin-recomp-flags.run plugin-recomp-flags [normal] (pre_cmd failed: 2) Framework warnings: . T13701 [numfield-no-expected] (No expected value found for bytes allocated in num_field check) I’ll send you the info you wanted for T10420 in a separate email. Thanks for helping! Simon From: Phyx Sent: 13 June 2018 20:47 To: Simon Peyton Jones Cc: ghc-devs@haskell.org Subject: Re: Strace Hi Simon, On Wed, Jun 13, 2018 at 5:24 PM, Simon Peyton Jones mailto:simo...@microsoft.com>> wrote: OK – so maybe the root cause is a framework failure – and indeed for the last few weeks I’ve seen Framework failures: plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) plugins/T10420.run T10420 [normal] (pre_cmd failed: 2) plugins/T11244.run T11244 [normal] (pre_cmd failed: 2) I have just learned to live with these failures, because I knew you were working on making things better. But it sounds as if they are still taking place. The commit I made should have reduced the amount of failing tests to 0. framework failures are always quite unusual. So: * Yes, please make it not happen by default I've removed the code, if you update it should be gone. It was there and on by default because I was trying to debug failures on Harbormaster, I realized a switch isn't very useful as I won't be able to toggle it for Harbormaster anyway. * * If you don’t get these framework failures, can we work together to resolve them? These don't happen for me nor on Harbormaster, try picking a test, e.g T10420 run only that test to make sure it's not a threading issue: make TEST=T10420 test -C testsuite/tests If it still gives a framework error then do at the top level make VERBOSE=3 TEST=T10420 test -C testsuite/tests once it runs, the output should contain the command it ran as a pre_cmd, and the stdout and stderr from the pre_cmd output. Could you then send the error? if it doesn't show any of this, try make CLEANP=0 VERBOSE=3 TEST= T10420 test -C testsuite/tests --trace and copy and paste the pre_cmd command, which should just replay the action it did. Cheers, Tamar Thanks Simon From: Phyx mailto:loneti...@gmail.com>> Sent: 13 June 2018 17:19 To: Simon Peyton Jones mailto:simo...@microsoft.com>> Cc: ghc-devs@haskell.org<mailto:ghc-devs@haskell.org> Subject: Re: Strace Hi Simon, The strace is only supposed to run when the normal test pre_cmd fails. If it's running that often it means your tests are all failing during pre_cmd with a framework failure https://git.haskell.org/ghc.git/blobdiff/4778cba1dbb6adf495930322d7f9e9db0af60d8f..60fb2b2160aa16194b74262f4df8fad5af171b0f:/testsuite/driver/testlib.py But maybe I shouldn't turn this on my default. I'll pramaterize it
Re: Strace
Hi Simon, On Wed, Jun 13, 2018 at 5:24 PM, Simon Peyton Jones wrote: > OK – so maybe the root cause is a framework failure – and indeed for the > last few weeks I’ve seen > > Framework failures: > >plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) > >plugins/T10420.run T10420 [normal] (pre_cmd failed: 2) > >plugins/T11244.run T11244 [normal] (pre_cmd failed: 2) > > > > I have just learned to live with these failures, because I knew you were > working on making things better. But it sounds as if they are still taking > place. > The commit I made should have reduced the amount of failing tests to 0. framework failures are always quite unusual. > > So: > >- Yes, please make it not happen by default > > I've removed the code, if you update it should be gone. It was there and on by default because I was trying to debug failures on Harbormaster, I realized a switch isn't very useful as I won't be able to toggle it for Harbormaster anyway. > >- >- If you don’t get these framework failures, can we work together to >resolve them? > > These don't happen for me nor on Harbormaster, try picking a test, e.g T10420 run only that test to make sure it's not a threading issue: make TEST=T10420 test -C testsuite/tests If it still gives a framework error then do at the top level make VERBOSE=3 TEST=T10420 test -C testsuite/tests once it runs, the output should contain the command it ran as a pre_cmd, and the stdout and stderr from the pre_cmd output. Could you then send the error? if it doesn't show any of this, try make CLEANP=0 VERBOSE=3 TEST= T10420 test -C testsuite/tests --trace and copy and paste the pre_cmd command, which should just replay the action it did. Cheers, Tamar > > Thanks > > > > Simon > > > > *From:* Phyx > *Sent:* 13 June 2018 17:19 > *To:* Simon Peyton Jones > *Cc:* ghc-devs@haskell.org > *Subject:* Re: Strace > > > > Hi Simon, > > > > The strace is only supposed to run when the normal test pre_cmd fails. > > If it's running that often it means your tests are all failing during > pre_cmd with a framework failure > > https://git.haskell.org/ghc.git/blobdiff/4778cba1dbb6adf495930322d7f9e9 > db0af60d8f..60fb2b2160aa16194b74262f4df8fad5af171b0f:/testsuite/driver/ > testlib.py > > > > But maybe I shouldn't turn this on my default. I'll pramaterize it when I > get home. > > > > Tamar. > > > > On Wed, Jun 13, 2018, 17:09 Simon Peyton Jones > wrote: > > Tamar > > I’m getting *megabytes* of output from ‘sh validate’ on windows. It > looks like this > > 629 151745 [main] sh 2880 fhandler_base::fhaccess: returning 0 > > 291 152036 [main] sh 2880 faccessat: returning 0 > > 7757 159793 [main] sh 2880 fhandler_base_overlapped::wait_overlapped: > wfres 0, wores 1, bytes 7 > > 179457 1608947 [main] make 11484 fhandler_base_overlapped::wait_overlapped: > wfres 0, wores 1, bytes 7 > >99 159892 [main] sh 2880 fhandler_base_overlapped::wait_overlapped: > normal write, 7 bytes ispipe() 1 > > 180 1609127 [main] make 11484 fhandler_base_overlapped::wait_overlapped: > normal read, 7 bytes ispipe() 1 > > 139 160031 [main] sh 2880 write: 7 = write(1, 0x6000396A0, 7) > > 142 1609269 [main] make 11484 fhandler_base::read: returning 7, binary > mode > > 139 1609408 [main] make 11484 read: 7 = read(5, 0x60005B4B0, 7) > > 136 1609544 [main] make 11484 read: read(5, 0x60005B4B7, 193) blocking > > 4693 164724 [main] sh 2880 set_signal_mask: setmask 0, newmask 8, > mask_bits 0 > > but with hundreds of thousands of lines. (I have not counted) > > I believe that it may be the result of this line, earlier in the log > > cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-8fa9s6rk/test > spaces/./plugins/plugins07.run" && *strace* $MAKE -s --no-print-directory > -C rule-defining-plugin package.plugins07 TOP=/c/code/HEAD/testsuite# > > Note the strace. > > That in turn was added in your commit > > commit 60fb2b2160aa16194b74262f4df8fad5af171b0f > > Author: Tamar Christina > > Date: Mon May 28 19:34:11 2018 +0100 > > > > Clean up Windows testsuite failures > > > > Summary: > > Another round and attempt at getting these down to 0. > > Could you perhaps have made a mistake here? Currently validate is > unusable. > > Thanks! > > Simon > > > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Strace
OK – so maybe the root cause is a framework failure – and indeed for the last few weeks I’ve seen Framework failures: plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) plugins/T10420.run T10420 [normal] (pre_cmd failed: 2) plugins/T11244.run T11244 [normal] (pre_cmd failed: 2) I have just learned to live with these failures, because I knew you were working on making things better. But it sounds as if they are still taking place. So: * Yes, please make it not happen by default * If you don’t get these framework failures, can we work together to resolve them? Thanks Simon From: Phyx Sent: 13 June 2018 17:19 To: Simon Peyton Jones Cc: ghc-devs@haskell.org Subject: Re: Strace Hi Simon, The strace is only supposed to run when the normal test pre_cmd fails. If it's running that often it means your tests are all failing during pre_cmd with a framework failure https://git.haskell.org/ghc.git/blobdiff/4778cba1dbb6adf495930322d7f9e9db0af60d8f..60fb2b2160aa16194b74262f4df8fad5af171b0f:/testsuite/driver/testlib.py But maybe I shouldn't turn this on my default. I'll pramaterize it when I get home. Tamar. On Wed, Jun 13, 2018, 17:09 Simon Peyton Jones mailto:simo...@microsoft.com>> wrote: Tamar I’m getting megabytes of output from ‘sh validate’ on windows. It looks like this 629 151745 [main] sh 2880 fhandler_base::fhaccess: returning 0 291 152036 [main] sh 2880 faccessat: returning 0 7757 159793 [main] sh 2880 fhandler_base_overlapped::wait_overlapped: wfres 0, wores 1, bytes 7 179457 1608947 [main] make 11484 fhandler_base_overlapped::wait_overlapped: wfres 0, wores 1, bytes 7 99 159892 [main] sh 2880 fhandler_base_overlapped::wait_overlapped: normal write, 7 bytes ispipe() 1 180 1609127 [main] make 11484 fhandler_base_overlapped::wait_overlapped: normal read, 7 bytes ispipe() 1 139 160031 [main] sh 2880 write: 7 = write(1, 0x6000396A0, 7) 142 1609269 [main] make 11484 fhandler_base::read: returning 7, binary mode 139 1609408 [main] make 11484 read: 7 = read(5, 0x60005B4B0, 7) 136 1609544 [main] make 11484 read: read(5, 0x60005B4B7, 193) blocking 4693 164724 [main] sh 2880 set_signal_mask: setmask 0, newmask 8, mask_bits 0 but with hundreds of thousands of lines. (I have not counted) I believe that it may be the result of this line, earlier in the log cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-8fa9s6rk/test spaces/./plugins/plugins07.run" && strace $MAKE -s --no-print-directory -C rule-defining-plugin package.plugins07 TOP=/c/code/HEAD/testsuite# Note the strace. That in turn was added in your commit commit 60fb2b2160aa16194b74262f4df8fad5af171b0f Author: Tamar Christina mailto:ta...@zhox.com>> Date: Mon May 28 19:34:11 2018 +0100 Clean up Windows testsuite failures Summary: Another round and attempt at getting these down to 0. Could you perhaps have made a mistake here? Currently validate is unusable. Thanks! Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Strace
Hi Simon, The strace is only supposed to run when the normal test pre_cmd fails. If it's running that often it means your tests are all failing during pre_cmd with a framework failure https://git.haskell.org/ghc.git/blobdiff/4778cba1dbb6adf495930322d7f9e9db0af60d8f..60fb2b2160aa16194b74262f4df8fad5af171b0f:/testsuite/driver/testlib.py But maybe I shouldn't turn this on my default. I'll pramaterize it when I get home. Tamar. On Wed, Jun 13, 2018, 17:09 Simon Peyton Jones wrote: > Tamar > > I’m getting *megabytes* of output from ‘sh validate’ on windows. It > looks like this > > 629 151745 [main] sh 2880 fhandler_base::fhaccess: returning 0 > > 291 152036 [main] sh 2880 faccessat: returning 0 > > 7757 159793 [main] sh 2880 fhandler_base_overlapped::wait_overlapped: > wfres 0, wores 1, bytes 7 > > 179457 1608947 [main] make 11484 > fhandler_base_overlapped::wait_overlapped: wfres 0, wores 1, bytes 7 > >99 159892 [main] sh 2880 fhandler_base_overlapped::wait_overlapped: > normal write, 7 bytes ispipe() 1 > > 180 1609127 [main] make 11484 fhandler_base_overlapped::wait_overlapped: > normal read, 7 bytes ispipe() 1 > > 139 160031 [main] sh 2880 write: 7 = write(1, 0x6000396A0, 7) > > 142 1609269 [main] make 11484 fhandler_base::read: returning 7, binary > mode > > 139 1609408 [main] make 11484 read: 7 = read(5, 0x60005B4B0, 7) > > 136 1609544 [main] make 11484 read: read(5, 0x60005B4B7, 193) blocking > > 4693 164724 [main] sh 2880 set_signal_mask: setmask 0, newmask 8, > mask_bits 0 > > but with hundreds of thousands of lines. (I have not counted) > > I believe that it may be the result of this line, earlier in the log > > cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-8fa9s6rk/test > spaces/./plugins/plugins07.run" && *strace* $MAKE -s --no-print-directory > -C rule-defining-plugin package.plugins07 TOP=/c/code/HEAD/testsuite# > > Note the strace. > > That in turn was added in your commit > > commit 60fb2b2160aa16194b74262f4df8fad5af171b0f > > Author: Tamar Christina > > Date: Mon May 28 19:34:11 2018 +0100 > > > > Clean up Windows testsuite failures > > > > Summary: > > Another round and attempt at getting these down to 0. > > Could you perhaps have made a mistake here? Currently validate is > unusable. > > Thanks! > > Simon > > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs