RE: Strace

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: Strace

GHC - devs mailing list

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 <[hidden email]>
Sent: 26 June 2018 06:01
To: Simon Peyton Jones <[hidden email]>
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","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

 

 

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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Strace

Phyx
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 <[hidden email]> 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 <[hidden email]>
Sent: 26 June 2018 06:01
To: Simon Peyton Jones <[hidden email]>
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","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

 

 

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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs