cvs commit: fptools/ghc/rts Main.c

[Julian Seward (Intl Vendor)]

Ken

Sounds like a potential memory management/corruption bug.
Do you have an example program which causes this to happen
on Alpha, so we can see if it can be repro'd on other plats?

J

| -----Original Message-----
| From: ken@glass.cse.ogi.edu [mailto:ken@glass.cse.ogi.edu]=20
| Sent: Thursday, July 26, 2001 4:21 AM
| To: cvs-ghc@haskell.org
| Subject: cvs commit: fptools/ghc/rts Main.c
|=20
|=20
| ken         2001/07/25 20:20:52 PDT
|=20
|   Modified files:
|     ghc/rts              Main.c=20
|   Log:
|   Added to main():
|  =20
|      /*
|       * Believe it or not, calling tzset() at startup seems=20
| to get rid of
|       * a scheduler-related Heisenbug on alpha-dec-osf3.  The=20
| symptom of
|       * the bug is that, when the load on the machine is high or when
|       * there are many threads, the variable "Capability *cap" in the
|       * function "schedule" in the file "Schedule.c" magically becomes
|       * null before the line "t =3D cap->rCurrentTSO;".  Why,=20
| and why does
|       * calling tzset() here seem to fix it?  Excellent questions!
|       */
|      tzset();
|  =20
|   Revision  Changes    Path
|   1.28      +16 -1     fptools/ghc/rts/Main.c
|=20
| _______________________________________________
| Cvs-ghc mailing list
| Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
|=20
|=20