Hi Ian, On Wednesday 14 January 2009 21:17, Ian Lynagh wrote: > > Hi Thorkil, > > On Tue, Jan 13, 2009 at 11:30:48PM +0100, Thorkil Naur wrote: > > > > > codeGen/StgCmmBind.hs:20:0: > > > Warning: Redundant import of: `cgExpr' > > > It is also imported from StgCmmExpr at > > codeGen/StgCmmBind.hs:18:0-16 > > Fix this, after briefly being confused by the mention of cgExpr. > It's actually complaining about two "import StgCmmExpr" declarations.
Thanks. > > > > typecheck/TcTyClsDecls.lhs:53:0: > > > Warning: Redundant import of: `Boxed' > > > It is also imported from BasicTypes at > > typecheck/TcTyClsDecls.lhs:17:0-16 > > This is similar; fixed. And thanks again. > > > debug_hi -hcsuf debug_hc -osuf debug_o -optc-DDEBUG -c sm/Scav.c -o > > sm/Scav.debug_o > > > cc1: warnings being treated as errors > > > sm/Scav.c: In function 'scavengeTSO': > > > > > > sm/Scav.c:72:0: > > > warning: format '%d' expects type 'int', but argument 3 has type > > 'StgThreadID' > > Simon said he is looking at this, so I haven't done so. No problem, I'll just keep my work-around. > > > with nothing happening for hours. I Ctrl-C'ed it and tried again and it hung > > in the same place. > > > > All the repeated attempts mentioned were sh validate with --no-clean, so I > > decided now to try sh validate without --no-clean. That resulted in a hang > > here: > > > > > $ sh validate > > > rm -f -rf inplace-datadir > > > make -C bindisttest distclean > > > rm -f -rf installed > > > rm -f -rf ghc* > > > rm -f HelloWorld HelloWorld.o HelloWorld.hi output > > > if test -d testsuite; then make -C testsuite distclean; fi > > > ^C^C > > Cleaning the testsuite was accidentally running GHC. I've now fixed > that, but is sounds like the real problem is that your GHC diverges. > > Presumably running > ghc/stage2-inplace/ghc > also just sits there? If so, you could try running > ghc/stage2-inplace/ghc -v > and > ghc/stage2-inplace/libexec/ghc > for more clues. You are right, GHC just hangs there. Unfortunately, -v and running the executable directly does not seem to provide any additional clues: GHC is silent here. > > You could also try doing the same after recompiling GHC to use the > debugging, and not the threaded, RTS: > cd ghc > make clean stage=2; make stage=2 GhcDebugged=YES GhcThreaded=NO > and if you're lucky then running ghc under gdb and hitting ^C after a > while will reveal the problem. The problem, unfortunately, disappears when using GhcThreaded=NO. However, I was still able to do something: Mac OS X 10.5 (Leopard) has a new thing called dtrace (replacing the ktrace that was present on 10.4 (Tiger)). I read about dtrace several years ago (it is originally a Sun thing) and was pleasantly surprised when I read in a recent article that it had been ported to Mac OS X (and also FreeBSD, by the way). I have only played a little with dtrace a while back, so I am just an amateur, but it appears to be quite powerful. However, one clearly needs experience to use it effectively, so bear with me. Getting back to the hanging ghc (with, by default, I presume, GhcThreaded=YES), I used dtruss (one dtrace interface) to get this trace of system calls: > thorkil-naurs-mac-mini:~ thorkilnaur$ sudo dtruss -p 85715 > Password: > SYSCALL(args) = return > sigreturn(0xBFFFEAB8, 0x1, 0xBFFFEAB8) = 0 Err#-2 > sigreturn(0xBFFFEAB8, 0x1, 0xBFFFEAB8) = 0 Err#-2 > ... And that's all that happens in terms of system calls, as I read this. But dtrace is also capable of tracing function entries and returns within a running process, so we can do this: > thorkil-naurs-mac-mini:~ thorkilnaur$ sudo dtrace -n pid85715:::entry > dtrace: description 'pid85715:::entry' matched 123857 probes > CPU ID FUNCTION:NAME > 0 137169 _sigtramp:entry > 0 134022 handle_tick:entry > 0 133655 handleProfTick:entry > 0 133491 setContextSwitches:entry > 0 139075 __finish_sigtramp:entry > 0 137289 sigreturn:entry > 0 136427 semaphore_wait:entry > 0 135557 semaphore_wait_trap:entry > 0 137169 _sigtramp:entry > 0 134022 handle_tick:entry > ... And that sequence just repeats, presumably endlessly. This traces just the entry of these functions, it is possible to get more details, but if you ask for everything, dtrace gives up for lack of memory, so I'll just leave it at this for now. Finally (GhcDebugged=YES), I tried running GHC in gdb, Ctrl-C and look around. What I saw was this: > thorkil-naurs-mac-mini:~/tn/test/GHC/PE195-performance-problem/work thorkilnaur$ gdb /Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling-and-copying-20070713_1212/ghc/ghc/stage2-inplace/libexec/ghc > GNU gdb 6.3.50-20050815 (Apple version gdb-954) (Mon Apr 14 03:54:19 UTC 2008) > ... > warning: Unable to read symbols from "GMP" (not yet mapped into memory). > Reading symbols for shared libraries ..... done > > (gdb) run -B/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling-and-copying-20070713_1212/ghc/inplace-datadir/. -dynload wrapped --version +RTS -DSs > Starting program: /Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling-and-copying-20070713_1212/ghc/ghc/stage2-inplace/libexec/ghc -B/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling-and-copying-20070713_1212/ghc/inplace-datadir/. -dynload wrapped --version +RTS -DSs > Reading symbols for shared libraries +++.+. done > a0992830: allocated 1 capabilities > ^C > Program received signal SIGINT, Interrupt. > <signal handler called> > (gdb) where > #0 <signal handler called> > Cannot access memory at address 0xa0000d4 > (gdb) ... > (gdb) cont > Continuing. > ^C > Program received signal SIGINT, Interrupt. > 0x94be61a8 in semaphore_wait_trap () > (gdb) where > #0 0x94be61a8 in semaphore_wait_trap () > #1 0x94bed424 in pthread_mutex_lock () > #2 0x01342f00 in newBoundTask () at Task.c:153 > #3 0x0132d03c in rts_lock () at RtsAPI.c:568 > #4 0x013304f4 in hs_add_root (init_root=0x103b8 <__stginit_ZCMain>) at RtsStartup.c:335 > #5 0x013304c4 in startupHaskell (argc=5, argv=0xbffff3e4, init_root=0x103b8 <__stginit_ZCMain>) at RtsStartup.c:294 > #6 0x01326550 in real_main () at Main.c:57 > #7 0x013266d8 in main (argc=7, argv=0xbffff3e4) at Main.c:156 > (gdb) cont > Continuing. > ^C > ... > (gdb) info threads > * 1 process 20926 local thread 0x301b 0x94be61a8 in semaphore_wait_trap () > (gdb) info thread > Thread 0x813 (local 0x301b) has current state "WAITING" > Thread 0x813 has a suspend count of 0. > (gdb) where > #0 0x94be61a8 in semaphore_wait_trap () > #1 0x94bed424 in pthread_mutex_lock () > #2 0x01342f00 in newBoundTask () at Task.c:153 > #3 0x0132d03c in rts_lock () at RtsAPI.c:568 > #4 0x013304f4 in hs_add_root (init_root=0x103b8 <__stginit_ZCMain>) at RtsStartup.c:335 > #5 0x013304c4 in startupHaskell (argc=5, argv=0xbffff3e4, init_root=0x103b8 <__stginit_ZCMain>) at RtsStartup.c:294 > #6 0x01326550 in real_main () at Main.c:57 > #7 0x013266d8 in main (argc=7, argv=0xbffff3e4) at Main.c:156 > (gdb) > I recognize some of the functions from the dtrace entry trace from the GHC RTS. In the next step, I would look at the involved code in more detail and try to figure out what goes on, possibly helped by suitable instrumentation. But in the meantime, I thought I would let have a look at it and hope that you might provide some hints. > > > Thanks > Ian > > Thanks and best regards Thorkil _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
