Should heapCensus work with threaded programs?

2010-12-06 Thread Ben Lippmeier
Hi Simon, Threaded programs are crashing for me with heap profiling turned on. I've only seen them crash with an interval < 0.1s. They seem fine with -N1. I have multiple crashing programs like so: > limitingfactor:dph-quickhull-vector benl$ pwd > /Users/benl/devel/ghc/build/baseline/ghc-head/li

[nightly] 06-Dec-2010 build of HEAD on i386-unknown-linux (cam-02-unx)

2010-12-06 Thread GHC Build Reports
Build description = HEAD on i386-unknown-linux (cam-02-unx) Build location= /playpen/simonmar/nightly/HEAD Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-02-unx Nightly build started on cam-02-unx at Mon Dec 6 18:00:02 GMT 2010. checking out new source tree

pgj-freebsd-i386-stable (x86 FreeBSD STABLE), build 82, Success

2010-12-06 Thread Builder
pgj-freebsd-i386-stable (x86 FreeBSD STABLE), build 82 Build succeeded Details: http://darcs.haskell.org/ghcBuilder/builders/pgj-freebsd-i386-stable/82.html darcs checkout | Success create mk/build.mk | Success get subrepos | Success repo versions| Success setting version

pgj-freebsd-amd64-stable (amd64 FreeBSD STABLE), build 99, Failure

2010-12-06 Thread Builder
pgj-freebsd-amd64-stable (amd64 FreeBSD STABLE), build 99 Build failed Details: http://darcs.haskell.org/ghcBuilder/builders/pgj-freebsd-amd64-stable/99.html darcs checkout | Success create mk/build.mk | Success get subrepos | Success repo versions| Success setting versio

[nightly] 06-Dec-2010 build of STABLE on i386-unknown-linux (cam-02-unx)

2010-12-06 Thread GHC Build Reports
Build description = STABLE on i386-unknown-linux (cam-02-unx) Build location= /playpen/simonmar/nightly/STABLE Build config file = /home/simonmar/nightly/site/msrc/conf-STABLE-cam-02-unx Nightly build started on cam-02-unx at Mon Dec 6 18:10:02 GMT 2010. checking out new source tree

pgj2 (amd64 FreeBSD HEAD), build 217, Failure

2010-12-06 Thread Builder
pgj2 (amd64 FreeBSD HEAD), build 217 Build failed Details: http://darcs.haskell.org/ghcBuilder/builders/pgj2/217.html darcs checkout | Success create mk/build.mk | Success get subrepos | Success repo versions| Success setting version date | Success booting | S

kchugalinskiy (x86 Windows HEAD), build 2, Failure

2010-12-06 Thread Builder
kchugalinskiy (x86 Windows HEAD), build 2 Build failed Details: http://darcs.haskell.org/ghcBuilder/builders/kchugalinskiy/2.html darcs checkout | Success create mk/build.mk | Failure: Just (ExitFailure 1) Build failed Details: http://darcs.haskell.org/ghcBuilder/builders/kchugalinskiy/2.htm

pgj (x86 FreeBSD HEAD), build 219, Success

2010-12-06 Thread Builder
pgj (x86 FreeBSD HEAD), build 219 Build succeeded Details: http://darcs.haskell.org/ghcBuilder/builders/pgj/219.html darcs checkout | Success create mk/build.mk | Success get subrepos | Success repo versions| Success setting version date | Success booting | Su

tn23 (x86 OSX HEAD), build 210, Success

2010-12-06 Thread Builder
tn23 (x86 OSX HEAD), build 210 Build succeeded Details: http://darcs.haskell.org/ghcBuilder/builders/tn23/210.html darcs checkout | Success create mk/build.mk | Success get subrepos | Success repo versions| Success setting version date | Success booting | Succ

Re: Linker problems on OSX.

2010-12-06 Thread Ian Lynagh
On Tue, Dec 07, 2010 at 12:59:43AM +, Ian Lynagh wrote: > On Tue, Dec 07, 2010 at 12:34:50AM +, Ian Lynagh wrote: > > On Mon, Dec 06, 2010 at 12:39:38PM +1100, Ben Lippmeier wrote: > > > > > > After we applied the latest OSX patches to our server, my build is now > > > dying like so: > >

[nightly] 06-Dec-2010 build of HEAD on x86_64-unknown-linux (cam-04-unx)

2010-12-06 Thread GHC Build Reports
Build description = HEAD on x86_64-unknown-linux (cam-04-unx) Build location= /64playpen/simonmar/nightly/HEAD-cam-04-unx Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-04-unx Nightly build started on cam-04-unx at Mon Dec 6 18:00:02 GMT 2010. checking out new source t

Re: Linker problems on OSX.

2010-12-06 Thread Ian Lynagh
On Tue, Dec 07, 2010 at 12:34:50AM +, Ian Lynagh wrote: > On Mon, Dec 06, 2010 at 12:39:38PM +1100, Ben Lippmeier wrote: > > > > After we applied the latest OSX patches to our server, my build is now > > dying like so: > > Can you test whether the attached patch fixes it please? Sorry, bad

[nightly] 06-Dec-2010 build of STABLE on x86_64-unknown-linux (cam-04-unx)

2010-12-06 Thread GHC Build Reports
Build description = STABLE on x86_64-unknown-linux (cam-04-unx) Build location= /64playpen/simonmar/nightly/STABLE-cam-04-unx Build config file = /home/simonmar/nightly/site/msrc/conf-STABLE-cam-04-unx Nightly build started on cam-04-unx at Mon Dec 6 18:10:01 GMT 2010. checking out new so

Re: Linker problems on OSX.

2010-12-06 Thread Ian Lynagh
On Mon, Dec 06, 2010 at 12:39:38PM +1100, Ben Lippmeier wrote: > > After we applied the latest OSX patches to our server, my build is now dying > like so: Can you test whether the attached patch fixes it please? Thanks Ian 4 patches for repository http://darcs.haskell.org/ghc: Mon Dec 6 20:

darcs patch: Filter out -optP-traditional from cmm build options

2010-12-06 Thread gwright
1 patch for repository http://darcs.haskell.org/ghc-7.0/ghc: Mon Dec 6 15:04:13 EST 2010 gwri...@antiope.com * Filter out -optP-traditional from cmm build options The build fails if SRC_HC_OPTS contains -optP-traditional because making .cmm files requires stripping out comments, which t

RE: patch applied (packages/integer-gmp): Fix unknown symbol base_ControlziExceptionziBase_patError_info by helping GHC generate smarter core.

2010-12-06 Thread Edward Z. Yang
Excerpts from Simon Peyton-Jones's message of Mon Dec 06 03:25:20 -0500 2010: > It would be good to document this trick. I think what is happening is that > patError is not defined until 'base' so we don't want it referred to by > 'integer-gmp'. Is that right? It sounds a bit fragile but probabl

mbolingbroke (x86 OSX HEAD), build 40, Failure

2010-12-06 Thread Builder
mbolingbroke (x86 OSX HEAD), build 40 Build failed Details: http://darcs.haskell.org/ghcBuilder/builders/mbolingbroke/40.html darcs checkout | Success create mk/build.mk | Success get subrepos | Success repo versions| Success setting version date | Success booting

Re: patch applied (ghc): Tell gcc to support back to OS X 10.5

2010-12-06 Thread Roman Leshchinskiy
On 03/12/2010, at 21:01, Ian Lynagh wrote: > Fri Dec 3 12:15:58 PST 2010 Ian Lynagh > * Tell gcc to support back to OS X 10.5 This breaks the build on 10.6 for me. It fails with: "/usr/bin/gcc" -o utils/unlit/dist/build/tmp/unlit -march=i686 -m32 -isysroot /Developer/SDKs/MacOSX10.5.sdk -m

sparky (Sparc Solaris HEAD), build 137, Failure

2010-12-06 Thread Builder
sparky (Sparc Solaris HEAD), build 137 Build failed Details: http://darcs.haskell.org/ghcBuilder/builders/sparky/137.html darcs checkout | Success create mk/build.mk | Success get subrepos | Success repo versions | Failure: Just (ExitFailure 29) Build failed Details: http://darcs.

simonmar-win32-stable (x86 Windows STABLE), build 119, Incomplete

2010-12-06 Thread Builder
simonmar-win32-stable (x86 Windows STABLE), build 119 Build incomplete Details: http://darcs.haskell.org/ghcBuilder/builders/simonmar-win32-stable/119.html Build incomplete Details: http://darcs.haskell.org/ghcBuilder/builders/simonmar-win32-stable/119.html __

simonmar-win32-head (Europe/London), build 183, Incomplete

2010-12-06 Thread Builder
simonmar-win32-head (Europe/London), build 183 Build incomplete Details: http://darcs.haskell.org/ghcBuilder/builders/simonmar-win32-head/183.html Build incomplete Details: http://darcs.haskell.org/ghcBuilder/builders/simonmar-win32-head/183.html _

RE: patch applied (packages/integer-gmp): Fix unknown symbol base_ControlziExceptionziBase_patError_info by helping GHC generate smarter core.

2010-12-06 Thread Simon Peyton-Jones
It would be good to document this trick. I think what is happening is that patError is not defined until 'base' so we don't want it referred to by 'integer-gmp'. Is that right? It sounds a bit fragile but probably not worth meddling. Why doesn't the linker sort it out, since 'base' is always