- Glasgow-haskell-users

RE: schedule: re-entered unsafely - with heavy concurrent load
by Simon Marlow 19 Feb '05

19 Feb '05

On 18 February 2005 22:15, Einar Karttunen wrote: > I am having problems with the threaded rts (6.5.20050207) > dying with 'schedule: re-entered unsafely'. The same code > seems to work with 6.2.2 with threaded rts. > > The exact error message is: > "foo: schedule: re-entered unsafely. > Perhaps a 'foreign import unsafe' should be 'safe'?" I fixed a bug that might cause this in the last couple of days. Could you try again with a fresh build and let us know if the problem still occurs? Cheers, Simon

2 1

RE: compiling GHC with a custom path to GCC
by Simon Marlow 18 Feb '05

18 Feb '05

On 18 February 2005 10:17, Seth Kurtzberg wrote: > Simon, you'll never give up. The crashes are absolutely repeatable. > The fact that I haven't identified a deterministic way to reproduce > them does not in any way imply that a deterministic way to reproduce > them does not exist. And, as I've said, you are essentially claiming > that a total of over 100 machines all have the same hardware problem, > that never ever occurs unless gcc is running. I'm not *claiming* anything about your case - please read what I said. I simply commented that random crashes in gcc are often caused by hardware failure. Indeed it sounds like hardware isn't the problem in your case, so I suggest you try to narrow down the problem and submit a report to the gcc folks. Cheers, Simon

2 1

schedule: re-entered unsafely - with heavy concurrent load
by Einar Karttunen 18 Feb '05

18 Feb '05

Hello I am having problems with the threaded rts (6.5.20050207) dying with 'schedule: re-entered unsafely'. The same code seems to work with 6.2.2 with threaded rts. The exact error message is: "foo: schedule: re-entered unsafely. Perhaps a 'foreign import unsafe' should be 'safe'?" I originally notices the problem with networking code which didn't use any of Network (nor threadWaitX). However the error appeared even with the standard libraries tipping in the direction of a bug in the rts. The code works most of the time, but has a small probability of failing when load is high. The test case implements a dummy web server which can be tried with e.g. apache benchmark (ab), /usr/sbin/ab2 -c 1000 -n 5000 127.0.0.1:8080/foo usually crashes the code when run a few times. The code should be compiled and run as ghc --make -threaded foo.hs -o foo && ./foo 8080 import Network import Control.Concurrent import qualified Control.Exception as E import System import System.IO main = do [port] <- getArgs server port server port = do s <- listenOn $ PortNumber $ fromIntegral $ read port acceptLoop s acceptLoop sock = do (csock,_,_) <- accept sock forkIO (handle csock `E.catch` print) acceptLoop sock handle sock = do hPutStr sock "HTTP/1.0 200 OK\r\nContent-Type: text/plain\r\n\r\n" hPutStr sock ("This is the body for the request to\n"++"hope you like this.\n\nnow garbage:\n") hClose sock - Einar Karttunen

1 0

RE: Dynamic loading problem
by Simon Marlow 18 Feb '05

18 Feb '05

On 30 April 2004 11:26, Duncan Coutts wrote: > Could someone remind me what the remaining issues are in getting ghc > to build Haskell modules/packaged into unix .so shared libraries? > > As I recall it seems to nearly work. Andre Pang got them to load and > function but it was a bit fragile and the rts would complain after a > short while: > http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg03923.h tml It might be possible to do this, but only if you want to do dlopen()-style linking at runtime. Linking a haskell binary against Haskell .so libraries still isn't possible - I had another look at this recently, and although one of the obstacles has been removed, there are others (details available on request). Any remaining issues to do with dlopen()ing a Haskell .so library are probably to do with CAFs. The dynamically loaded code needs to call newDynCAF() instead of newCAF() in a CAF's entry code - this is normally arranged by the RTS linker, but for a .so you'll have to do it some other way, like getting the compiler to emit the different call, or doing some CPP magic (but only for -fvia-C). Any reasonable patches to implement this will be incorporated. Oh, and strictly speaking we should run the __stginit_Foo() function from each dynamically loaded module. But the RTS linker still doesn't do this. Cheers, Simon

4 3

RE: Restricted Types and Infinite Loops
by Simon Peyton-Jones 18 Feb '05

18 Feb '05

Simon You've found an interesting case. First, you are skating on thin ice here. GHC's ability to build recursive dictionaries is quite experimental, and you are relying on it completely. But you're right: it "should" work. I can see why it isn't but I have not got it clear enough in my head to know the best way to fix it. Still less do I have a formal story about what should type-check (without loops) and what should not. So this is going to continue to fail in 6.4, but it's on my list to look at. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Simon David Foster | Sent: 27 January 2005 14:11 | To: GHC Users | Subject: Restricted Types and Infinite Loops | | Hi, | | (I've attached the full code for this problem) | | First I'll explain the problem description, I have two class ClassA and | ClassB, the former has two parameters and the latter has one. The second | parameter of ClassA is constrained by ClassB. | | class ClassB a where | class ClassB b => ClassA a b where | | Because I wish to effectively pass the context of ClassA around, I need | to create a pair of dictionary types (as in Restricted Data Types in | Haskell, Hughes 99), one to represent ClassA (DictClassA) and one to | represent ClassB (DictClassB). DictClassA also contains a term of type | DictClassB since ClassA is a subclass of ClassB. I should then be able | to call all the functions of ClassB via the appropriate term of | DictClassA, like so (assuming we want to use func2); | | *Test> func2D (classBD (dict::DictClassA Int String)) "hello" | "bye" | | So far so good, but now suppose I want Class A to have the further | constraint | | class (Data (DictClassA a) b, ClassB b) => ClassA a b where | | (so as to make ClassA a subclass of Data) | | If we now try and do | | *Test> func2D (classBD (dict::DictClassA Int String)) "hello" | | We go into an infinite loop. Why? The expression still type-checks ok | and I can't see what it is trying to do. All the functions of ClassA can | be accessed ok, but not ClassB. | | *Test> funcD ((dict::DictClassA Int String)) "hello" 5 | "hello" | | Is it something to do with ClassB only having one parameter? | | I'm running GHC 20041231. | | -Si. | | -- | Simon David Foster <s.d.f(a)btinternet.com>

2 1

RE: ghc-cvs-snapshot with wxHaskell
by Simon Marlow 18 Feb '05

18 Feb '05

On 17 February 2005 20:24, Georg Martius wrote: > 2. Stub files (@Simon) > The problem I ran into was that the FILE_stub.o files are not placed > at the correct(?) directory according to the position of FILE in the > hierarchical library. > Example: > ghc -c wxcore/src/Graphics/UI/WXCore/Events.hs -o > out/wxcore/imports/Graphics/UI/WXCore/Events.o -fvia-C -package-name > wxcore -iwxcore/src -odir out/wxcore/imports -hidir > out/wxcore/imports -iout/wxcore/imports -Iwxc/include > > produces > out/wxcore/imports/Events_stub.o > instead of > out/wxcore/imports/Graphics/UI/WXCore/Events_stub.o > I don't know if it is the expected behaviour? I just looked at the code, this is a can of worms. I don't think I can fix it this close to the release without breaking anything else, so if you can manage with this behaviour then I'll leave it as is. Later, we can try to determine what the right behaviour should be with respect to stub files and the interactions with --make, hierarchical modules and -odir. Right now it's making my head hurt a bit. Cheers, Simon

1 0

RE: compiling GHC with a custom path to GCC
by Simon Marlow 18 Feb '05

18 Feb '05

On 18 February 2005 04:26, Seth Kurtzberg wrote: > At least this proves that it isn't a hardware problem. :) Seth, you're a bit confused. This error from gcc is a deterministic, repeatable, crash due to a known bug in gcc 2.95. You were complaining about random unrepeatable crashes, which are most likely caused by hardware failure. We never said that deterministic crashes in gcc are due to hardware. Cheers, Simon

3 2

Restricted Types and Infinite Loops
by Simon David Foster 18 Feb '05

18 Feb '05

Hi, (I've attached the full code for this problem) First I'll explain the problem description, I have two class ClassA and ClassB, the former has two parameters and the latter has one. The second parameter of ClassA is constrained by ClassB. class ClassB a where class ClassB b => ClassA a b where Because I wish to effectively pass the context of ClassA around, I need to create a pair of dictionary types (as in Restricted Data Types in Haskell, Hughes 99), one to represent ClassA (DictClassA) and one to represent ClassB (DictClassB). DictClassA also contains a term of type DictClassB since ClassA is a subclass of ClassB. I should then be able to call all the functions of ClassB via the appropriate term of DictClassA, like so (assuming we want to use func2); *Test> func2D (classBD (dict::DictClassA Int String)) "hello" "bye" So far so good, but now suppose I want Class A to have the further constraint class (Data (DictClassA a) b, ClassB b) => ClassA a b where (so as to make ClassA a subclass of Data) If we now try and do *Test> func2D (classBD (dict::DictClassA Int String)) "hello" We go into an infinite loop. Why? The expression still type-checks ok and I can't see what it is trying to do. All the functions of ClassA can be accessed ok, but not ClassB. *Test> funcD ((dict::DictClassA Int String)) "hello" 5 "hello" Is it something to do with ClassB only having one parameter? I'm running GHC 20041231. -Si. -- Simon David Foster <s.d.f(a)btinternet.com>

3 6

RE: compiling GHC with a custom path to GCC
by Simon Marlow 18 Feb '05

18 Feb '05

On 18 February 2005 09:38, Remi Turk wrote: >>> On Thu, Feb 17, 2005 at 11:29:41AM -0000, Simon Marlow wrote: >>>> I've noticed gcc 2.95 crashing on my FreeBSD box too. I should >>>> look into whether there's a workaround, otherwise we're hosed on >>>> FreeBSD 4.x. > > (though I now assume it probably isn't even the same bug?) Yes, it's the same bug. Simon

1 0

RE: compiling GHC with a custom path to GCC
by Simon Marlow 18 Feb '05

18 Feb '05

On 18 February 2005 01:02, Donald Bruce Stewart wrote: > This is a known problem with gcc-2.95. > We came across it back in September. > > It was noticed in the nightly builds: > > http://www.haskell.org/pipermail/cvs-all/2004-September/035116.html > > And then we chased it up: > > http://www.haskell.org/pipermail/cvs-all/2004-September/035122.html > http://www.haskell.org/pipermail/cvs-all/2004-September/035134.html > http://www.haskell.org/pipermail/cvs-all/2004-September/035259.html > http://www.haskell.org/pipermail/cvs-all/2004-September/035268.html > http://www.haskell.org/pipermail/cvs-all/2004-September/035293.html Don, thanks for the pointer, I'd completely forgotten about that. I think I'll be able to install a workaround for 6.4 based on the gcc version. I need it at least because FreeBSD 4.x still uses gcc 2.95, and AFAIK quite a few folks are still using that platform. Cheers, Simon

1 0