[M3devel] freebsd 10

[mika at async.caltech.edu]

Peter, have you/someone run the thread tester exhaustively?

I did this:

#!/bin/csh

while ( 1 ) 
        limit cputime 5
        rm -rf AMD64_FREEBSD/ ; cm3 ; AMD64_FREEBSD/threadtest
end

With what's in FreeBSD's ports I get a variety of failures:


1.
***
*** runtime error:
***    Segmentation violation - possible attempt to dereference NIL
***    pc = 0x417c78 = Init + 0xe6 in ../src/rw/FileRd.m3
***

2.
running...printing oldest/median age/newest
.Assertion failed: (e == 0), function ThreadPThread__pthread_mutex_delete, file ../src/thread/PTHREAD/ThreadPThreadC.c, line 473.

3. (most common)
***
*** runtime error:
***    Segmentation violation - possible attempt to dereference NIL
***    pc = 0x4387e8 = Move + 0x6a in ../src/runtime/common/RTCollector.m3
***

4.
***
*** runtime error:
***    Segmentation violation - possible attempt to dereference NIL
***    pc = 0x417c78 = Init + 0xe6 in ../src/rw/FileRd.m3
***

5. (letting it run a bit longer)
!!! lock Thread 23 appears starved or deadlocked !!!

This is all running in a single-cpu instance (M3.medium) of EC2...  usually things get worse with more processors.

FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014
    root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
XEN: Hypervisor version 4.2 detected.
CPU: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz (2495.93-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x306e4  Family = 0x6  Model = 0x3e  Stepping = 4
  Features=0x1783fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT>
  Features2=0xffba2203<SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV>
  AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
  AMD Features2=0x1<LAHF>
  Standard Extended Features=0x200<ENHMOVSB>
real memory  = 4026531840 (3840 MB)
avail memory = 3872776192 (3693 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: <Xen HVM>




>>>>>

Hi

I think tony put a fix into the collector that fixes that problem. The scheduler with pthreads is more agressive and under high load the mutator could have a newly allocated page collected before the object was initalised. would be good if you check it . There was a report of an assert failure a few days ago in the region of code affected, if we could find out which assert failed I could take a look. 
The only other problem is the odd failure in forking. Seems to occur in the child process in initstackbase which initiates a collection which then finds a weak ref to a mutex which is in a thread that does not exist in the child. Not sure what to do about that.
The pthreads seems pretty stable at least on linux. 

Peter