Re: 6.4.3 and threaded RTS problems
Could someone on MacOS X try the 6.4.x branch again? I just committed a fix that makes the threaded RTS more stable on Solaris, and I'm hoping it clears up the problems on MacOS X too. Remember to re-enable -threaded in ghc/compiler/Makefile if you previously disabled it. The problem seems to be solved now, great work! Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4.3 and threaded RTS problems
Wolfgang Thaller wrote: Could someone on MacOS X try the 6.4.x branch again? I just committed a fix that makes the threaded RTS more stable on Solaris, and I'm hoping it clears up the problems on MacOS X too. Remember to re-enable -threaded in ghc/compiler/Makefile if you previously disabled it. The problem seems to be solved now, great work! That was quick, thanks Wolfgang. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4.3 and threaded RTS problems
David Kirkman wrote: I ran the testsuite against the current HEAD (as of saturday afternoon) and had far fewer failures. Is the last week's work supposed to have fixed so many test cases? Or are different machines giving different results? The tests that resulted in unexpected failures for greg were all run on my machine, but many of them worked on my setup. We have put some work into cleaning up the test failures, currently the x86_64/Linux build (my main dev environment) is at 28 failures, most of which are probably not real bugs. Unexpected passes: barton-mangler-bug(optasm) cholewo-eval(optasm,profasm) these two are susceptible to floating-point differences, I wouldn't worry about them. Unexpected failures: TH_repPatSig(normal) barton-mangler-bug(opt) conc019(opt) conc024(normal) conc039(threaded1) conc056(threaded1) ffi009(ghci) ffi016(normal,prof) the conc and ffi failures are worrying. gadt7(normal) galois_raytrace(opt,prof) maessen_hashtab(normal,opt,optasm,prof,profasm,ghci,threaded1) rnfail026(normal) signals002(ghci) tcfail068(normal) tcfail071(normal) tcfail090(normal) tcfail099(normal) tcfail103(normal) tcfail115(normal) tcfail140(normal) tcrun021(normal,opt,optasm,prof,profasm,ghci,threaded1) these are all known, except for galoiis_raytrace which is probably a floating-point difference. utf8_002(normal) utf8_003(normal) utf8_004(normal) utf8_005(normal) I believe you can make these go away by installing the latest Alex from darcs. It's nothing to worry about, I made a small tweak to Alex that improved the error messages from GHC's lexer. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4.3 and threaded RTS problems
I'll run the latest on my G4 tonight and we can see. Best Wishes, Greg On Aug 28, 2006, at 12:05 AM, David Kirkman wrote: I ran the testsuite against the current HEAD (as of saturday afternoon) and had far fewer failures. Is the last week's work supposed to have fixed so many test cases? Or are different machines giving different results? The tests that resulted in unexpected failures for greg were all run on my machine, but many of them worked on my setup. -david k. -- Results for a lightly loaded dual proc G5 running OS 10.4.7. OVERALL SUMMARY for test run started at Sat Aug 26 19:00:07 PDT 2006 1434 total tests, which gave rise to 6334 test cases, of which 0 caused framework failures 1107 were skipped 5138 expected passes 47 expected failures 3 unexpected passes 39 unexpected failures Unexpected passes: barton-mangler-bug(optasm) cholewo-eval(optasm,profasm) Unexpected failures: TH_repPatSig(normal) barton-mangler-bug(opt) conc019(opt) conc024(normal) conc039(threaded1) conc056(threaded1) ffi009(ghci) ffi016(normal,prof) gadt7(normal) galois_raytrace(opt,prof) maessen_hashtab(normal,opt,optasm,prof,profasm,ghci,threaded1) rnfail026(normal) signals002(ghci) tcfail068(normal) tcfail071(normal) tcfail090(normal) tcfail099(normal) tcfail103(normal) tcfail115(normal) tcfail140(normal) tcrun021(normal,opt,optasm,prof,profasm,ghci,threaded1) utf8_002(normal) utf8_003(normal) utf8_004(normal) utf8_005(normal) On 8/24/06, Gregory Wright [EMAIL PROTECTED] wrote: Here's what happened (this is after I applied David Kirkman's SMP.h patch to my tree). When I said 132 failures I was speaking from memory. The actual number was 136, as noted in the log: OVERALL SUMMARY for test run started at Mon Aug 14 11:20:03 EDT 2006 1412 total tests, which gave rise to 4711 test cases, of which 0 caused framework failures 658 were skipped 3882 expected passes 32 expected failures 3 unexpected passes 136 unexpected failures Unexpected passes: barton-mangler-bug(optasm) cholewo-eval(optasm) ds052(normal) Unexpected failures: TH_spliceE5_prof(normal) arr004(normal,opt,optasm) arr007(opt,optasm) barton-mangler-bug(opt,threaded2) cabal01(normal) cabal02(normal) cg016(normal,opt,optasm) cg051(opt,optasm) conc012(normal) conc014(opt,optasm) conc021(opt,optasm) conc024(normal,opt,optasm) conc034(normal,opt,optasm) conc037(threaded2) conc039(threaded1) conc052(opt) conc056(threaded1,threaded2) concprog001(normal,opt,optasm) concprog002(threaded2) dsrun005(opt,optasm) dsrun007(opt,optasm) dsrun008(opt,optasm) enum01(normal,opt,optasm) enum02(normal,opt,optasm) enum03(normal,opt,optasm) exceptions001(normal,opt,optasm) exceptions002(opt,optasm) forkprocess01(ghci) galois_raytrace(opt,threaded2) ghci013(ghci) ghcpkg04(normal) joao-circular(optasm) list001(normal,opt,optasm) maessen_hashtab(normal,opt,optasm,ghci,threaded1,threaded2) mod1(normal) mod150(normal) mod151(normal) mod152(normal) mod153(normal) mod2(normal) net001(normal,opt,optasm,ghci,threaded1,threaded2) net002(normal,opt,optasm,ghci,threaded1,threaded2) newtype(opt) pkg02_b(normal,opt,optasm) read003(normal) rw(normal) seward-space-leak(ghci) signals002(ghci) simpl011(normal,opt,optasm) strun002(opt) tc102(normal,opt,optasm) tc134(normal,opt,optasm) tc136(normal,opt,optasm) tc141(normal,opt,optasm) tcfail068(normal) tcfail071(normal) tcfail082(normal) tcfail090(normal) tcfail099(normal) tcfail103(normal) tcfail115(normal) tcfail140(normal) tcrun021(normal,opt,optasm,ghci,threaded1,threaded2) uri001(normal,opt,optasm,ghci,threaded1,threaded2) utf8_002(normal) utf8_003(normal) utf8_004(normal) utf8_005(normal) Cheers, Simon /Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re: 6.4.3 and threaded RTS problems
I ran the testsuite against the current HEAD (as of saturday afternoon) and had far fewer failures. Is the last week's work supposed to have fixed so many test cases? Or are different machines giving different results? The tests that resulted in unexpected failures for greg were all run on my machine, but many of them worked on my setup. -david k. -- Results for a lightly loaded dual proc G5 running OS 10.4.7. OVERALL SUMMARY for test run started at Sat Aug 26 19:00:07 PDT 2006 1434 total tests, which gave rise to 6334 test cases, of which 0 caused framework failures 1107 were skipped 5138 expected passes 47 expected failures 3 unexpected passes 39 unexpected failures Unexpected passes: barton-mangler-bug(optasm) cholewo-eval(optasm,profasm) Unexpected failures: TH_repPatSig(normal) barton-mangler-bug(opt) conc019(opt) conc024(normal) conc039(threaded1) conc056(threaded1) ffi009(ghci) ffi016(normal,prof) gadt7(normal) galois_raytrace(opt,prof) maessen_hashtab(normal,opt,optasm,prof,profasm,ghci,threaded1) rnfail026(normal) signals002(ghci) tcfail068(normal) tcfail071(normal) tcfail090(normal) tcfail099(normal) tcfail103(normal) tcfail115(normal) tcfail140(normal) tcrun021(normal,opt,optasm,prof,profasm,ghci,threaded1) utf8_002(normal) utf8_003(normal) utf8_004(normal) utf8_005(normal) On 8/24/06, Gregory Wright [EMAIL PROTECTED] wrote: Here's what happened (this is after I applied David Kirkman's SMP.h patch to my tree). When I said 132 failures I was speaking from memory. The actual number was 136, as noted in the log: OVERALL SUMMARY for test run started at Mon Aug 14 11:20:03 EDT 2006 1412 total tests, which gave rise to 4711 test cases, of which 0 caused framework failures 658 were skipped 3882 expected passes 32 expected failures 3 unexpected passes 136 unexpected failures Unexpected passes: barton-mangler-bug(optasm) cholewo-eval(optasm) ds052(normal) Unexpected failures: TH_spliceE5_prof(normal) arr004(normal,opt,optasm) arr007(opt,optasm) barton-mangler-bug(opt,threaded2) cabal01(normal) cabal02(normal) cg016(normal,opt,optasm) cg051(opt,optasm) conc012(normal) conc014(opt,optasm) conc021(opt,optasm) conc024(normal,opt,optasm) conc034(normal,opt,optasm) conc037(threaded2) conc039(threaded1) conc052(opt) conc056(threaded1,threaded2) concprog001(normal,opt,optasm) concprog002(threaded2) dsrun005(opt,optasm) dsrun007(opt,optasm) dsrun008(opt,optasm) enum01(normal,opt,optasm) enum02(normal,opt,optasm) enum03(normal,opt,optasm) exceptions001(normal,opt,optasm) exceptions002(opt,optasm) forkprocess01(ghci) galois_raytrace(opt,threaded2) ghci013(ghci) ghcpkg04(normal) joao-circular(optasm) list001(normal,opt,optasm) maessen_hashtab(normal,opt,optasm,ghci,threaded1,threaded2) mod1(normal) mod150(normal) mod151(normal) mod152(normal) mod153(normal) mod2(normal) net001(normal,opt,optasm,ghci,threaded1,threaded2) net002(normal,opt,optasm,ghci,threaded1,threaded2) newtype(opt) pkg02_b(normal,opt,optasm) read003(normal) rw(normal) seward-space-leak(ghci) signals002(ghci) simpl011(normal,opt,optasm) strun002(opt) tc102(normal,opt,optasm) tc134(normal,opt,optasm) tc136(normal,opt,optasm) tc141(normal,opt,optasm) tcfail068(normal) tcfail071(normal) tcfail082(normal) tcfail090(normal) tcfail099(normal) tcfail103(normal) tcfail115(normal) tcfail140(normal) tcrun021(normal,opt,optasm,ghci,threaded1,threaded2) uri001(normal,opt,optasm,ghci,threaded1,threaded2) utf8_002(normal) utf8_003(normal) utf8_004(normal) utf8_005(normal) Cheers, Simon /Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4.3 and threaded RTS problems
On Thu, 2006-08-24 at 08:56 +0100, Simon Marlow wrote: Hi Folks, Roman Leshchinskiy and I looked into the 6.4.3 crashes on Sparc/Solaris yesterday. I think we may have found the problem, and it seems likely that this is the same problem affecting 6.4.3 on MacOS X. The threaded RTS is assuming in a couple of places that pthread_cond_wait() doesn't spuriously wake up, which is apparently the case on Linux but not true in general. I don't believe it is the case on Linux either. I had the same problem: on Linux it appears to work .. but Posix allows spurious wakeups, our OSX/Solaris/Windows code failed. This isn't just for cond_wait: most system calls can return spuriously if an OS signal goes off. Somewhere I read a good article explaining why this is necessary for good performance. A signal to a condition variable should be regarded as a hint to recheck the condition. -- John Skaller skaller at users dot sf dot net Felix, successor to C++: http://felix.sf.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4.3 and threaded RTS problems
Worse is Better gives an entertaining view on this fact. pepe On 24/08/06, skaller [EMAIL PROTECTED] wrote: On Thu, 2006-08-24 at 08:56 +0100, Simon Marlow wrote: Hi Folks, Roman Leshchinskiy and I looked into the 6.4.3 crashes on Sparc/Solaris yesterday. I think we may have found the problem, and it seems likely that this is the same problem affecting 6.4.3 on MacOS X. The threaded RTS is assuming in a couple of places that pthread_cond_wait() doesn't spuriously wake up, which is apparently the case on Linux but not true in general. I don't believe it is the case on Linux either. I had the same problem: on Linux it appears to work .. but Posix allows spurious wakeups, our OSX/Solaris/Windows code failed. This isn't just for cond_wait: most system calls can return spuriously if an OS signal goes off. Somewhere I read a good article explaining why this is necessary for good performance. A signal to a condition variable should be regarded as a hint to recheck the condition. -- John Skaller skaller at users dot sf dot net Felix, successor to C++: http://felix.sf.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4.3 and threaded RTS problems
Hi Simon, On Aug 24, 2006, at 3:56 AM, Simon Marlow wrote: Hi Folks, Roman Leshchinskiy and I looked into the 6.4.3 crashes on Sparc/ Solaris yesterday. I think we may have found the problem, and it seems likely that this is the same problem affecting 6.4.3 on MacOS X. The threaded RTS is assuming in a couple of places that pthread_cond_wait() doesn't spuriously wake up, which is apparently the case on Linux but not true in general. I don't think this bug affects 6.6. I could be wrong, however. Does anyone on MacOS X have a recent testsuite run with the HEAD? I'll try to put together a fix for 6.4.3 when the 6.6 release cycle has died down. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users I built HEAD and ran ghc-regress last week. It looks like the compiler crashes are almost all gone. There are still 132 unexpected failures, but only one compiler crash. There are quite a number of RTS system crashes, but I do get tracebacks. I haven't looked at all of the crashes, but a number of them fail as conc052 does below, in RaiseAsync.c . ** Host Name: gregory-wrights-powerbook-g4-17 Date/Time: 2006-08-14 12:09:02.560 -0400 OS Version: 10.4.7 (Build 8J135) Report Version: 4 Command: conc052 Path:./conc052 Parent: sh [1344] Version: ??? (???) PID:1345 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xfffc Thread 0 Crashed: 0 conc052 0x00217020 raiseAsync + 496 (RaiseAsync.c:924) 1 conc052 0x0020fe3c scheduleDoGC + 204 (Schedule.c:2038) 2 conc052 0x00211390 scheduleWaitThread + 2032 (Schedule.c:704) 3 conc052 0x001feb20 main + 48 (Main.c:106) 4 conc052 0x1ab4 _start + 340 (crt.c:272) 5 conc052 0x195c start + 60 Thread 0 crashed with PPC Thread State 64: srr0: 0x00217020 srr1: 0xf030vrsave: 0x cr: 0x22002244 xer: 0x0004 lr: 0x00216fb4 ctr: 0x r0: 0x0015d044 r1: 0xb6c0 r2: 0x0025 r3: 0x015d7094 r4: 0x0006 r5: 0x0002 r6: 0x0001 r7: 0x r8: 0xfff8 r9: 0x r10: 0x002e r11: 0x0156c014 r12: 0x900016c0 r13: 0x r14: 0x r15: 0x r16: 0x r17: 0x r18: 0x r19: 0x r20: 0x00204978 r21: 0x r22: 0x0001 r23: 0x0026a000 r24: 0x r25: 0x015794a0 r26: 0x015d7094 r27: 0x01579100 r28: 0x0003 r29: 0x0002 r30: 0x015794ac r31: 0x015794ac Binary Images Description: 0x1000 - 0x241fff conc052 /Users/gwright/src/haskell/ghc/ testsuite/tests/ghc-regress/concurrent/should_run/conc052 0x8fe0 - 0x8fe52fff dyld 45.3 /usr/lib/dyld 0x9000 - 0x901bbfff libSystem.B.dylib /usr/lib/libSystem.B.dylib 0x90213000 - 0x90218fff libmathCommon.A.dylib /usr/lib/system/ libmathCommon.A.dylib I can probably do a bit of testing in the next few weeks, but am on a deadline for getting some chip design work done. Alas, I am having to spend more time debugging my haskell simulation, which constantly blows stack, than fixing the circuit itself :-( Best, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4.3 and threaded RTS problems
Gregory Wright wrote: I built HEAD and ran ghc-regress last week. It looks like the compiler crashes are almost all gone. There are still 132 unexpected failures, but only one compiler crash. Are these crashes all for the threaded2 way? We'll probably need to disable SMP on PPC for the 6.6 release, because I'm fairly sure it doesn't work (the workarounds we need for the weaker memory ordering on PPC aren't implemented). Ian is planning to sort this out before the release. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4.3 and threaded RTS problems
Hi Simon, On Aug 24, 2006, at 7:34 AM, Simon Marlow wrote: Gregory Wright wrote: I built HEAD and ran ghc-regress last week. It looks like the compiler crashes are almost all gone. There are still 132 unexpected failures, but only one compiler crash. Are these crashes all for the threaded2 way? We'll probably need to disable SMP on PPC for the 6.6 release, because I'm fairly sure it doesn't work (the workarounds we need for the weaker memory ordering on PPC aren't implemented). Ian is planning to sort this out before the release. Here's what happened (this is after I applied David Kirkman's SMP.h patch to my tree). When I said 132 failures I was speaking from memory. The actual number was 136, as noted in the log: OVERALL SUMMARY for test run started at Mon Aug 14 11:20:03 EDT 2006 1412 total tests, which gave rise to 4711 test cases, of which 0 caused framework failures 658 were skipped 3882 expected passes 32 expected failures 3 unexpected passes 136 unexpected failures Unexpected passes: barton-mangler-bug(optasm) cholewo-eval(optasm) ds052(normal) Unexpected failures: TH_spliceE5_prof(normal) arr004(normal,opt,optasm) arr007(opt,optasm) barton-mangler-bug(opt,threaded2) cabal01(normal) cabal02(normal) cg016(normal,opt,optasm) cg051(opt,optasm) conc012(normal) conc014(opt,optasm) conc021(opt,optasm) conc024(normal,opt,optasm) conc034(normal,opt,optasm) conc037(threaded2) conc039(threaded1) conc052(opt) conc056(threaded1,threaded2) concprog001(normal,opt,optasm) concprog002(threaded2) dsrun005(opt,optasm) dsrun007(opt,optasm) dsrun008(opt,optasm) enum01(normal,opt,optasm) enum02(normal,opt,optasm) enum03(normal,opt,optasm) exceptions001(normal,opt,optasm) exceptions002(opt,optasm) forkprocess01(ghci) galois_raytrace(opt,threaded2) ghci013(ghci) ghcpkg04(normal) joao-circular(optasm) list001(normal,opt,optasm) maessen_hashtab(normal,opt,optasm,ghci,threaded1,threaded2) mod1(normal) mod150(normal) mod151(normal) mod152(normal) mod153(normal) mod2(normal) net001(normal,opt,optasm,ghci,threaded1,threaded2) net002(normal,opt,optasm,ghci,threaded1,threaded2) newtype(opt) pkg02_b(normal,opt,optasm) read003(normal) rw(normal) seward-space-leak(ghci) signals002(ghci) simpl011(normal,opt,optasm) strun002(opt) tc102(normal,opt,optasm) tc134(normal,opt,optasm) tc136(normal,opt,optasm) tc141(normal,opt,optasm) tcfail068(normal) tcfail071(normal) tcfail082(normal) tcfail090(normal) tcfail099(normal) tcfail103(normal) tcfail115(normal) tcfail140(normal) tcrun021(normal,opt,optasm,ghci,threaded1,threaded2) uri001(normal,opt,optasm,ghci,threaded1,threaded2) utf8_002(normal) utf8_003(normal) utf8_004(normal) utf8_005(normal) Cheers, Simon /Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.4.3 and threaded RTS problems
Hi Simon, On Aug 24, 2006, at 7:34 AM, Simon Marlow wrote: Gregory Wright wrote: I built HEAD and ran ghc-regress last week. It looks like the compiler crashes are almost all gone. There are still 132 unexpected failures, but only one compiler crash. Are these crashes all for the threaded2 way? We'll probably need to disable SMP on PPC for the 6.6 release, because I'm fairly sure it doesn't work (the workarounds we need for the weaker memory ordering on PPC aren't implemented). Ian is planning to sort this out before the release. Cheers, Simon For the record, here are the crashes (not test failures) from build of HEAD on OS X ppc. I will sort through them to find out how many distinct failures there seem to be. Fortunately, the all knowing haskell-cafe list has explained my laziness to me and thereby fixed my stack overflow woes. Henceforth I promise to be, if not diligent and hardworking, at least strict :-) And thanks to them I should be able to find a few moments to look at the crash logs. Best, greg gregory-wrights-powerbook-g4-17 cat crashes Aug 14 11:23:42 gregory-wrights-powerbook-g4-17 crashdump[18790]: arr007 crashed Aug 14 11:23:42 gregory-wrights-powerbook-g4-17 crashdump[18790]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ arr007.crash.log Aug 14 11:23:53 gregory-wrights-powerbook-g4-17 crashdump[18806]: arr007 crashed Aug 14 11:23:53 gregory-wrights-powerbook-g4-17 crashdump[18806]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ arr007.crash.log Aug 14 11:38:30 gregory-wrights-powerbook-g4-17 crashdump[22522]: cg016 crashed Aug 14 11:38:30 gregory-wrights-powerbook-g4-17 crashdump[22522]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ cg016.crash.log Aug 14 11:50:37 gregory-wrights-powerbook-g4-17 crashdump[25697]: concprog001 crashed Aug 14 11:50:37 gregory-wrights-powerbook-g4-17 crashdump[25697]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ concprog001.crash.log Aug 14 11:51:34 gregory-wrights-powerbook-g4-17 crashdump[25773]: concprog001 crashed Aug 14 11:51:34 gregory-wrights-powerbook-g4-17 crashdump[25773]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ concprog001.crash.log Aug 14 12:00:32 gregory-wrights-powerbook-g4-17 crashdump[27844]: conc012 crashed Aug 14 12:00:32 gregory-wrights-powerbook-g4-17 crashdump[27844]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ conc012.crash.log Aug 14 12:03:59 gregory-wrights-powerbook-g4-17 crashdump[29119]: conc024 crashed Aug 14 12:03:59 gregory-wrights-powerbook-g4-17 crashdump[29119]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ conc024.crash.log Aug 14 12:05:30 gregory-wrights-powerbook-g4-17 crashdump[29822]: conc034 crashed Aug 14 12:05:30 gregory-wrights-powerbook-g4-17 crashdump[29822]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ conc034.crash.log Aug 14 12:05:34 gregory-wrights-powerbook-g4-17 crashdump[29842]: conc034 crashed Aug 14 12:05:34 gregory-wrights-powerbook-g4-17 crashdump[29842]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ conc034.crash.log Aug 14 12:05:37 gregory-wrights-powerbook-g4-17 crashdump[29858]: conc034 crashed Aug 14 12:05:37 gregory-wrights-powerbook-g4-17 crashdump[29858]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ conc034.crash.log Aug 14 12:09:03 gregory-wrights-powerbook-g4-17 crashdump[1346]: conc052 crashed Aug 14 12:09:03 gregory-wrights-powerbook-g4-17 crashdump[1346]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ conc052.crash.log Aug 14 12:16:48 gregory-wrights-powerbook-g4-17 crashdump[4545]: dsrun005 crashed Aug 14 12:16:48 gregory-wrights-powerbook-g4-17 crashdump[4545]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ dsrun005.crash.log Aug 14 12:16:50 gregory-wrights-powerbook-g4-17 crashdump[4561]: dsrun005 crashed Aug 14 12:16:50 gregory-wrights-powerbook-g4-17 crashdump[4561]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ dsrun005.crash.log Aug 14 12:17:10 gregory-wrights-powerbook-g4-17 crashdump[4723]: dsrun007 crashed Aug 14 12:17:10 gregory-wrights-powerbook-g4-17 crashdump[4723]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ dsrun007.crash.log Aug 14 12:17:12 gregory-wrights-powerbook-g4-17 crashdump[4739]: dsrun007 crashed Aug 14 12:17:12 gregory-wrights-powerbook-g4-17 crashdump[4739]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ dsrun007.crash.log Aug 14 12:17:22 gregory-wrights-powerbook-g4-17 crashdump[4814]: dsrun008 crashed Aug 14 12:17:22 gregory-wrights-powerbook-g4-17 crashdump[4814]: crash report written to: /Users/gwright/Library/Logs/CrashReporter/ dsrun008.crash.log Aug 14 12:17:24 gregory-wrights-powerbook-g4-17
Re: 6.4.3 and threaded RTS problems
Gregory Wright wrote: Here's what happened (this is after I applied David Kirkman's SMP.h patch to my tree). When I said 132 failures I was speaking from memory. The actual number was 136, as noted in the log: OVERALL SUMMARY for test run started at Mon Aug 14 11:20:03 EDT 2006 1412 total tests, which gave rise to 4711 test cases, of which 0 caused framework failures 658 were skipped 3882 expected passes 32 expected failures 3 unexpected passes 136 unexpected failures Unexpected passes: barton-mangler-bug(optasm) cholewo-eval(optasm) ds052(normal) Unexpected failures: TH_spliceE5_prof(normal) arr004(normal,opt,optasm) arr007(opt,optasm) barton-mangler-bug(opt,threaded2) cabal01(normal) cabal02(normal) cg016(normal,opt,optasm) cg051(opt,optasm) conc012(normal) conc014(opt,optasm) conc021(opt,optasm) etc. Interesting - a lot of failures from tests that ran (rather than just compiled), and mostly just when compiled optimised. Thankfully this doesn't appear to be threading-related, as these tests are all running with the single-threaded RTS. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
