6.4.3 and threaded RTS problems

[Gregory Wright]

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 at 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