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 0xfffffffc 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 0x00001ab4 _start + 340 (crt.c:272) 5 conc052 0x0000195c start + 60 Thread 0 crashed with PPC Thread State 64: srr0: 0x0000000000217020 srr1: 0x000000000000f030 vrsave: 0x0000000000000000 cr: 0x22002244 xer: 0x0000000000000004 lr: 0x0000000000216fb4 ctr: 0x0000000000000000 r0: 0x000000000015d044 r1: 0x00000000bffff6c0 r2: 0x0000000000250000 r3: 0x00000000015d7094 r4: 0x0000000000000006 r5: 0x0000000000000002 r6: 0x0000000000000001 r7: 0x0000000000000000 r8: 0x00000000fffffff8 r9: 0x0000000000000000 r10: 0x000000000000002e r11: 0x000000000156c014 r12: 0x00000000900016c0 r13: 0x0000000000000000 r14: 0x0000000000000000 r15: 0x0000000000000000 r16: 0x0000000000000000 r17: 0x0000000000000000 r18: 0x0000000000000000 r19: 0x0000000000000000 r20: 0x0000000000204978 r21: 0x0000000000000000 r22: 0x0000000000000001 r23: 0x000000000026a000 r24: 0x0000000000000000 r25: 0x00000000015794a0 r26: 0x00000000015d7094 r27: 0x0000000001579100 r28: 0x0000000000000003 r29: 0x0000000000000002 r30: 0x00000000015794ac r31: 0x00000000015794ac Binary Images Description: 0x1000 - 0x241fff conc052 /Users/gwright/src/haskell/ghc/ testsuite/tests/ghc-regress/concurrent/should_run/conc052 0x8fe00000 - 0x8fe52fff dyld 45.3 /usr/lib/dyld 0x90000000 - 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