- ghc-devs - Haskell.org

linker_unload validate related issue (how to duplicate that?).
by Karel Gardas 07 Aug '14

07 Aug '14

Folks, I've noted that validate is failing on Linux recently due to issue in linker_unload. As I've submitted some patch to this test case recently which fixes this on Solaris I'm kind of curious if I broke it or not. Anyway, strange thing is: when I configure ghc and run the test by (g)make TEST=linker_unload on both Linux and Solaris I get no failure. When I validate on Linux (validate is not working on Solaris yet), then I get failure in linker_unload: Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: /bin/sh: 1: Syntax error: Unterminated quoted string make[3]: *** [linker_unload] Error 2 *** unexpected failure for linker_unload(normal) when I try to run: cd testsuite make TEST=linker_unload inside this validation tree I again get no failure in this test: [...] =====> linker_unload(normal) 2522 of 4082 [0, 0, 0] cd ./rts && $MAKE -s --no-print-directory linker_unload </dev/null >linker_unload.run.stdout 2>linker_unload.run.stderr OVERALL SUMMARY for test run started at Wed Aug 6 10:55:17 2014 CEST 0:00:08 spent to go through 4082 total tests, which gave rise to 13459 test cases, of which 13458 were skipped 0 had missing libraries 1 expected passes 0 expected failures 0 caused framework failures 0 unexpected passes 0 unexpected failures make[1]: Leaving directory `/home/karel/src/validate-test/testsuite/tests' I've also noted that this test case fails on Solaris builders with strange error: =====> linker_unload(normal) 170 of 4082 [0, 0, 1] cd ./rts && $MAKE -s --no-print-directory linker_unload </dev/null >linker_unload.run.stdout 2>linker_unload.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: linker_unload: internal error: loadObj: can't read `/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/bindisttest/install/libHSinteg_BcPVjqcazPNGsNFG4agFty.a' (GHC version 7.9.20140806 for i386_unknown_solaris2) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug gmake[3]: *** [linker_unload] Abort (core dumped) So the question is: why validate fails and why builder fails on this particular test and why my common testing on both Solaris and Linux is not able to duplicate the issue? What's so different between validate and builders and between my common: perl boot; ./configure <some params>; gmake -j12; cd testsuite; gmake THREADS=12 fast ? Thanks! Karel

2 3

Re: Perf regression: ghc --make: add nicer names to RTS threads (threaded IO manager, make workers) (f686682)
by Joachim Breitner 06 Aug '14

06 Aug '14

Hi Sergei, Am Mittwoch, den 06.08.2014, 22:15 +0300 schrieb Sergei Trofimovich: > On Wed, 06 Aug 2014 09:30:45 +0200 Joachim Breitner <mail(a)joachim-breitner.de> wrote: > > the attached commit seems to have regressed the scs nofib benchmark by > > ~3%: > > http://ghcspeed-nomeata.rhcloud.com/timeline/?ben=nofib/time/scs&env=1#/?ex… > > That's a test of compiled binary performance, not the compiler, right? Correct. > > The graph unfortunately is in the wrong order, as the tool gets confused > > by timezones and by commits with identical CommitDate, e.g. due to > > rebasing. This needs to be fixed, I manually verified that the commit > > below is the first that shows the above-noise-level-increase of runtime. > > > > (Other benchmarks seem to be unaffected.) > > > > Is this regression expected and intended or unexpected? Is it fixable? > > Or is is this simply inexplicable? > > The graph looks mysterious (18 ms bump). Bencmark does not use haskell > threads at all. Yes, I was surprised by that as well. > I'll try to reproduce degradation locally and will investigate. Thanks! > The only runtime part affected by the patch only renames threads > (the renamer gets called once for each created thread): > > > > diff --git a/libraries/base/GHC/Event/Thread.hs b/libraries/base/GHC/Event/Thread.hs > > > index 6e991bf..dcfa32a 100644 > > > --- a/libraries/base/GHC/Event/Thread.hs > > > +++ b/libraries/base/GHC/Event/Thread.hs > > > @@ -39,6 +39,7 @@ import GHC.Event.Manager (Event, EventManager, evtRead, evtWrite, loop, > > > import qualified GHC.Event.Manager as M > > > import qualified GHC.Event.TimerManager as TM > > > import GHC.Num ((-), (+)) > > > +import GHC.Show (showSignedInt) > > > import System.IO.Unsafe (unsafePerformIO) > > > import System.Posix.Types (Fd) > > > > > > @@ -244,11 +245,14 @@ startIOManagerThreads = > > > forM_ [0..high] (startIOManagerThread eventManagerArray) > > > writeIORef numEnabledEventManagers (high+1) > > > > > > +show_int :: Int -> String > > > +show_int i = showSignedInt 0 i "" > > > + > > > restartPollLoop :: EventManager -> Int -> IO ThreadId > > > restartPollLoop mgr i = do > > > M.release mgr > > > !t <- forkOn i $ loop mgr > > > - labelThread t "IOManager" > > > + labelThread t ("IOManager on cap " ++ show_int i) > > > return t > > > > > > startIOManagerThread :: IOArray Int (Maybe (ThreadId, EventManager)) > > > @@ -258,7 +262,7 @@ startIOManagerThread eventManagerArray i = do > > > let create = do > > > !mgr <- new True > > > !t <- forkOn i $ loop mgr > > > - labelThread t "IOManager" > > > + labelThread t ("IOManager on cap " ++ show_int i) > > > writeIOArray eventManagerArray i (Just (t,mgr)) > > > old <- readIOArray eventManagerArray i > > > case old of It does replace a reference to the a string ("IOManager") by something involving allocation and computation. I guess that could have a measurable effect. What happens to programs relying on very cheap threads? Do we have benchmarks for this class of programs at all? Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

1 0

Perf regression: ghc --make: add nicer names to RTS threads (threaded IO manager, make workers) (f686682)
by Joachim Breitner 06 Aug '14

06 Aug '14

Hi, the attached commit seems to have regressed the scs nofib benchmark by ~3%: http://ghcspeed-nomeata.rhcloud.com/timeline/?ben=nofib/time/scs&env=1#/?ex… The graph unfortunately is in the wrong order, as the tool gets confused by timezones and by commits with identical CommitDate, e.g. due to rebasing. This needs to be fixed, I manually verified that the commit below is the first that shows the above-noise-level-increase of runtime. (Other benchmarks seem to be unaffected.) Is this regression expected and intended or unexpected? Is it fixable? Or is is this simply inexplicable? Thanks, Joachim Am Montag, den 04.08.2014, 13:13 +0000 schrieb git(a)git.haskell.org: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/f6866824ce5cdf5359f0cad78c49d65f6… > > >--------------------------------------------------------------- > > commit f6866824ce5cdf5359f0cad78c49d65f6d43af12 > Author: Sergei Trofimovich <slyfox(a)gentoo.org> > Date: Mon Aug 4 08:10:33 2014 -0500 > > ghc --make: add nicer names to RTS threads (threaded IO manager, make workers) > > Summary: > The patch names most of RTS threads > and ghc (the tool) threads. > > It makes nicer debug and eventlog output for ghc itself. > > Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org> > > Test Plan: ran debugged ghc under '+RTS -Ds' > > Reviewers: simonmar, austin > > Reviewed By: austin > > Subscribers: phaskell, simonmar, relrod, ezyang, carter > > Differential Revision: https://phabricator.haskell.org/D101 > > > >--------------------------------------------------------------- > > f6866824ce5cdf5359f0cad78c49d65f6d43af12 > compiler/main/GhcMake.hs | 14 ++++++++++++++ > libraries/base/GHC/Event/Thread.hs | 8 ++++++-- > 2 files changed, 20 insertions(+), 2 deletions(-) > > diff --git a/compiler/main/GhcMake.hs b/compiler/main/GhcMake.hs > index 33f163c..0c63203 100644 > --- a/compiler/main/GhcMake.hs > +++ b/compiler/main/GhcMake.hs > @@ -63,6 +63,7 @@ import qualified Data.Set as Set > import qualified FiniteMap as Map ( insertListWith ) > > import Control.Concurrent ( forkIOWithUnmask, killThread ) > +import qualified GHC.Conc as CC > import Control.Concurrent.MVar > import Control.Concurrent.QSem > import Control.Exception > @@ -80,6 +81,11 @@ import System.IO.Error ( isDoesNotExistError ) > > import GHC.Conc ( getNumProcessors, getNumCapabilities, setNumCapabilities ) > > +label_self :: String -> IO () > +label_self thread_name = do > + self_tid <- CC.myThreadId > + CC.labelThread self_tid thread_name > + > -- ----------------------------------------------------------------------------- > -- Loading the program > > @@ -744,10 +750,18 @@ parUpsweep n_jobs old_hpt stable_mods cleanup sccs = do > | ((ms,mvar,_),idx) <- comp_graph_w_idx ] > > > + liftIO $ label_self "main --make thread" > -- For each module in the module graph, spawn a worker thread that will > -- compile this module. > let { spawnWorkers = forM comp_graph_w_idx $ \((mod,!mvar,!log_queue),!mod_idx) -> > forkIOWithUnmask $ \unmask -> do > + liftIO $ label_self $ unwords > + [ "worker --make thread" > + , "for module" > + , show (moduleNameString (ms_mod_name mod)) > + , "number" > + , show mod_idx > + ] > -- Replace the default log_action with one that writes each > -- message to the module's log_queue. The main thread will > -- deal with synchronously printing these messages. > diff --git a/libraries/base/GHC/Event/Thread.hs b/libraries/base/GHC/Event/Thread.hs > index 6e991bf..dcfa32a 100644 > --- a/libraries/base/GHC/Event/Thread.hs > +++ b/libraries/base/GHC/Event/Thread.hs > @@ -39,6 +39,7 @@ import GHC.Event.Manager (Event, EventManager, evtRead, evtWrite, loop, > import qualified GHC.Event.Manager as M > import qualified GHC.Event.TimerManager as TM > import GHC.Num ((-), (+)) > +import GHC.Show (showSignedInt) > import System.IO.Unsafe (unsafePerformIO) > import System.Posix.Types (Fd) > > @@ -244,11 +245,14 @@ startIOManagerThreads = > forM_ [0..high] (startIOManagerThread eventManagerArray) > writeIORef numEnabledEventManagers (high+1) > > +show_int :: Int -> String > +show_int i = showSignedInt 0 i "" > + > restartPollLoop :: EventManager -> Int -> IO ThreadId > restartPollLoop mgr i = do > M.release mgr > !t <- forkOn i $ loop mgr > - labelThread t "IOManager" > + labelThread t ("IOManager on cap " ++ show_int i) > return t > > startIOManagerThread :: IOArray Int (Maybe (ThreadId, EventManager)) > @@ -258,7 +262,7 @@ startIOManagerThread eventManagerArray i = do > let create = do > !mgr <- new True > !t <- forkOn i $ loop mgr > - labelThread t "IOManager" > + labelThread t ("IOManager on cap " ++ show_int i) > writeIOArray eventManagerArray i (Just (t,mgr)) > old <- readIOArray eventManagerArray i > case old of > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits > -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

1 0

Re: Haskell Platform 2014.2.0.0 Release Candidate 2
by George Colpitts 05 Aug '14

05 Aug '14

Yes, as you stated, not an HP problem. I did a cabal update and got past this problem. I still can't install threadscope but I don't believe this is an HP platform problem so I'll follow up with the threadscope people and won't post again to this group Thanks [10 of 35] Compiling GUI.ProgressView ( GUI/ProgressView.hs, dist/build/threadscope/threadscope-tmp/GUI/ProgressView.o ) GUI/ProgressView.hs:92:15: Could not deduce (System.Glib.UTFString.GlibString string0) arising from a use of ‘labelNew’ from the context (WindowClass win) bound by the type signature for new :: WindowClass win => win -> IO () -> IO ProgressView at GUI/ProgressView.hs:79:8-57 The type variable ‘string0’ is ambiguous Note: there are several potential instances: instance System.Glib.UTFString.GlibString text-1.1.0.0:Data.Text.Internal.Text -- Defined in ‘System.Glib.UTFString’ instance System.Glib.UTFString.GlibString [Char] -- Defined in ‘System.Glib.UTFString’ In a stmt of a 'do' block: progText <- labelNew Nothing In the expression: do { win <- windowNew; set win [containerBorderWidth := 10, windowTitle := "", ....]; progText <- labelNew Nothing; set progText [miscXalign := 0, labelUseMarkup := True]; .... } In an equation for ‘new’: new parent cancelAction = do { win <- windowNew; set win [containerBorderWidth := 10, ....]; progText <- labelNew Nothing; .... } cabal: Error: some packages failed to install: threadscope-0.2.4 failed during the building phase. The exception was: ExitFailure 1 On Tue, Jul 29, 2014 at 10:48 AM, Brandon Allbery <allbery.b(a)gmail.com> wrote: > On Tue, Jul 29, 2014 at 7:45 AM, George Colpitts < > george.colpitts(a)gmail.com> wrote: > >> Installation worked fine. However I encountered a problem that looks like >> a regression, although it may be a problem with new versions of the package >> I am trying to install: > > > It's not an H-P problem; Apple's started using their BLOCKS C extension in > system headers, and gtk2hsc2hs doesn't understand it. (And possibly is not > using cpp properly when processing headers.) You'll need to take this up > with the gtk2hs folks. > > #ifdef __BLOCKS__ > int scandir_b(const char *, struct dirent ***, > int (^)(const struct dirent *), int (^)(const struct dirent **, > const struct > dirent **)) __DARWIN_INODE64(scandir_b) > __OSX_AVAILABLE_STARTING(__MAC_10_6, __ > IPHONE_3_2); > #endif /* __BLOCKS__ */ > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b(a)gmail.com > ballbery(a)sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net >

1 0

Core Lint warnings
by Gabor Greif 05 Aug '14

05 Aug '14

Hello all, I see *literally thousands* of these warnings (in yesterday's and) today's bootstraps: {{{ HC [stage 1] libraries/base/dist-install/build/GHC/Base.o *** Core Lint warnings : in result of Desugar (after optimization) *** {-# LINE 261 "libraries/base/GHC/Base.lhs #-}: Warning: [RHS of $c>>_arr :: forall r_agf a_adQ b_adR. (r_agf -> a_adQ) -> (r_agf -> b_adR) -> r_agf -> b_adR] INLINE binder is (non-rule) loop breaker: $c>>_arr {-# LINE 632 "libraries/base/GHC/Base.lhs #-}: Warning: [RHS of $c>>_apH :: forall a_adQ b_adR. GHC.Types.IO a_adQ -> GHC.Types.IO b_adR -> GHC.Types.IO b_adR] INLINE binder is (non-rule) loop breaker: $c>>_apH }}} I don't know when this started and it does not seem to lead to a damaged GHC, but nevertheless it does not look very trustworthy... Any idea what this could be and where it came from? Cheers, Gabor

1 0

Interrupt interruptible foreign calls on HS exit
by Andreas Voellmy 05 Aug '14

05 Aug '14

Hi GHCers, I've been looking into issue #9284, which boils down to getting certain foreign calls issued by HS threads to finish (i.e. return) in the exit sequence of forkProcess. There are several options for solving the particular problem in #9284; one option is to issue the particular foreign calls causing that issue as "interruptible" and then have the exit sequence interrupt interruptible foreign calls. The exit sequence, starting from hs_exit(), goes through hs_exit_(), exitScheduler(), scheduleDoGC(), deleteAllThreads(), and then deleteThread(), where deleteThread is this: static void deleteThread (Capability *cap STG_UNUSED, StgTSO *tso) { // NOTE: must only be called on a TSO that we have exclusive // access to, because we will call throwToSingleThreaded() below. // The TSO must be on the run queue of the Capability we own, or // we must own all Capabilities. if (tso->why_blocked != BlockedOnCCall && tso->why_blocked != BlockedOnCCall_Interruptible) { throwToSingleThreaded(tso->cap,tso,NULL); } } So it looks like interruptible foreign calls are not interrupted in the exit sequence. Is there a good reason why we have this behavior? Could we change it to interrupt TSO's with why_blocked == BlockedOnCCall_Interruptible in the exit sequence? Thanks, Andi P.S. It looks like this was introduced in commit 83d563cb9ede0ba792836e529b1e2929db926355.

2 4

last call... for HP 2014.2.0.0
by Mark Lentczner 05 Aug '14

05 Aug '14

As it stands, I'm planning on calling the final RCs final: - RC2 Mac - RC4 Win - RC3 Src and linux-dist They have a few wibbles, but nothing close to show-stopping. I'll rebuild the web site and upload it tomorrow and announce then as well. - Mark ("still on vacation") L.

1 0

Re: Release building for Windows
by Mark Lentczner 05 Aug '14

05 Aug '14

Seems to me that given the state of affairs, it is best to just leave it as it is this round: That is GHC is built split-obj, but the HP libs on Windows are not. In general, split-obj only makes executables smaller at the expense of link time and memory. It is a trade-off, and I'd make the call for faster link, and now uncertainty for now. So, unless there is objection, I'd call RC4 final for Windows. - Mark

1 0

HEADS UP: linker symbols changed, need to recompile
by Edward Z. Yang 05 Aug '14

05 Aug '14

I've just pushed a set of patches which change the linker symbols GHC chooses for object files; you'll need to make clean and rebuild your tree once you take these changes. Thanks, Edward

1 0

Status updates
by Austin Seipp 05 Aug '14

05 Aug '14

Hi *, Here's some weekly status updates! - I'm merging Applicative-Monad today after a few more minor fixes. OMG YES. This only occurred after fighting off some nasty bugs that took quite a while to track down. Unfortunately this ate up most of my time this week. - I redid the Phabricator page quite a bit on the wiki, as I sent in my earlier email. Do read over it and let me know what you think, I'll be updating it more soon: https://ghc.haskell.org/trac/ghc/wiki/Phabricator - I'm going to be redoing the Git wiki pages a bit today to streamline them, which hopefully will only take a few hours. - I'm draining the patch queue still, both from Phabricator and Trac, although I need to re-triage a few of the Trac tickets in particular which are in 'patch' status. - We have a new committer afoot, Karel Gardas! Yay! He's been working on Solaris support, so having direct access to commit will surely help speed things up here. - DPH will soon be disabled by default in ./validate, although Geoff has stepped up to help alleviate some of the pain (see prior emails from me.) After all that: - I'm going to fix bugs! Yes, I'll actually have time to do that. - Sometime this week I'll also hopefully finish off my Phabricator integrations: better build bot, with accurate logs, and posting to Trac from Phabricator. This is *almost* done, but still needs to be tested/deployed a bit. - I may get around to finally pushing my patches for faster inline copies this week (and -march support) if I still have time. Do let me know if anything is on your mind, or if any of you have questions. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 2