Re: Bogus stats when running SMP programs

2006-09-26 Thread Ian Lynagh 

Hi Tomasz,

On Thu, Sep 21, 2006 at 08:03:53PM +0200, Tomasz Zielonka wrote:
 
 I am getting nonsensical execution statistics (+RTS -Sstderr) when
 running programs in SMP mode (+RTS -N2).
 Example:
 
   Task  0 (worker) :  MUT time: 401572821.14s  ( 21.89s elapsed)
   GC  time:   0.00s  (  0.00s elapsed)
 
   Task  3 (worker) :  MUT time: 401583421.14s  ( 21.91s elapsed)
   GC  time:   0.00s  (  0.00s elapsed)
 
 I am using ghc-6.5.20060919-i386-unknown-linux.tar.bz2 on
 Intel(R) Pentium(R) D CPU 3.20GHz (dual core) with
 kernel 2.6.16-2-686-smp (Debian 2.6.16-17).

I couldn't reproduce this with a simple program that forked off 4
threads to do computation on a single CPU machine, and neither could
someone on IRC with head from Sep 15 on a Core Duo.

Is it possible to send us a small example program along with exactly
what flags you used to compile and run it please?


Thanks
Ian

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Summary of GHC 6.6 test suite failures on MSYS/MinGW

2006-09-26 Thread Simon Marlow 

Brian Smith wrote:

On 9/25/06, *Ian Lynagh* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:

On Wed, Sep 13, 2006 at 12:23:27PM -0500, Brian Smith wrote:

  * conc023(ghci)
 
  This test only fails when run via GHCi. This test runs out of
memory. The
  error message to stderr is:
 conc023: failed to create OS thread: Not enough storage is
available to
  process this command.
 
  When I came back to the computer I saw that Windows was warning
me that I
  was out of virtual memory and that it was increasing my page file
size. I
  have 1GB of RAM which I think should be sufficient to run the
testsuite
  successfully.

Does that happen repeatably?


The test always failed. When I decreased the number of threads in the 
test from 5,000 to 1,400 or so, then the tests passed sometimes, and 
sometimes failed. Decreasing the number of threads to under a thousand 
made the test pass consistently. IIRC, the test failed almost 
immediately upon executing.


conc023 creates 5000 threads that all do threadDelay with varying delays.  On 
Windows, with both the threaded and non-threaded runtimes, this results in 5000 
OS threads being created, which is usually enough to fill up your VM.


I intend to fix this, at least in the threaded RTS, in fact it'll be part of the 
fix for http://hackage.haskell.org/trac/ghc/ticket/637.  The I/O manager thread 
handles sleeps and signals, but currently isn't implemented on Windows.


Now, when I tried to rerun the tests against the latest ghc-6.6, ghc.exe 
is segfaulting on ffi012(ghci), conc049(ghci), and conc023(ghci):


Unhandled exception at 0x0207fc58 in ghc.exe: 0xC005: Access violation.


That's a bit worrying...

Cheers,
Simon
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Summary of GHC 6.6 test suite failures on MSYS/MinGW

2006-09-26 Thread Brian Smith 
On 9/26/06, Simon Marlow [EMAIL PROTECTED] wrote:
Brian Smith wrote: The test always failed. When I decreased the number of threads in the test from 5,000 to 1,400 or so, then the tests passed sometimes, and sometimes failed. Decreasing the number of threads to under a thousand
 made the test pass consistently. IIRC, the test failed almost immediately upon executing.conc023 creates 5000 threads that all do threadDelay with varying delays.On Windows, with both the threaded and non-threaded runtimes, this results in 5000 OS threads being created, which is usually enough to fill up your VM.
I intend to fix this, at least in the threaded RTS, in fact it'll be part of the
fix for http://hackage.haskell.org/trac/ghc/ticket/637.The I/O manager threadhandles sleeps and signals, but currently isn't implemented on Windows.
It already passes in the threaded RTS and every other way except GHCi: normal, opt, optasm, prof, profasm, threaded1, and threaded2. That is what I thought was strange.Regards,Brian
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #909: problems building base package with --make; wired in things are assumed to not be in current package

2006-09-26 Thread GHC 
#909: problems building base package with --make; wired in things are assumed to
not be in current package
-+--
Reporter:  igloo |Owner:  simonpj
Type:  bug   |   Status:  new
Priority:  normal|Milestone:  6.8
   Component:  Compiler  |  Version:  6.4.2  
Severity:  normal| Keywords: 
  Os:  Multiple  |   Difficulty:  Unknown
Architecture:  Multiple  |  
-+--
GHC currently assumes that wired in things are not in the current package.
 This causes problems when the base package is partially compiled (in
 particular, GHC.Base is built already) and you try to build the whole
 thing with --make.
 Each time it needs something from GHC.Base, GHC looks to see if it has
 been loaded from another package yet and, upon finding it hasn't, loads it
 from the current package.
 This results in it loading it multiple times, giving errors like:
 {{{
 GHC/Foo.hs:6:6:
 Overlapping instances for Eq Bool
   arising from use of `==' at GHC/Foo.hs:6:6-17
 Matching instances:
   instance Eq Bool -- Defined in GHC.Base
   instance Eq Bool -- Defined in GHC.Base
   instance Eq Bool -- Defined in GHC.Base
 In the expression: True == True
 In the definition of `foo': foo = True == True
 }}}
 This is now tested by base01 in the testsuite.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/909
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs