No problems on any of my other BOINC projects. No problems with any of my games. My OS has never crashed. No faulty hardware. Everything verified as working as intended. Process of elimination in action. MCM has some faulty code somewhere. It doesn't happen on every work unit. I have troubleshooted every electronic part on my motherboard, memory chips, cpu, gpu, etc. No problems whatsoever. No overheating problems. Case has 9 fans. CPU and GPU are liquid cooled. I do not get paid to do QA work for the project. It is not my job to do that. Not my responsibility.

@rcthardcore

Actually, whilst you may well be right (though I suspect any issue is more likely to be in the support wrapper than the actual MCM1 application...) you haven't eliminated the possibility that on your system the combination of work you're running happens to find an issue in either the BOINC support code or somewhere in Windows that only adversely affects MCM1 in an obvious way.

I am not sure that it's just MCM1 at WCG that sees the "stuck task" syndrome - I've seen it reported at Einstein and MilkyWay on occasion (restarting BOINC or rebooting seem to be the recommended cures there too!) Hence my suggestion that it could be something in the BOINC support code that gets confused every now and then...

"Not my circus, not my monkey." Except that as a community we try to help one another, which includes some of us trying to establish the causes of problems that didn't show up at Beta Test time (there is no such thing as bug-free software, I fear!)

In your case I'd be interested to know several things:

• What BOINC client are you running?
  
• How many simultaneous BOINC tasks do you run?
  
• What other projects from WCG do you run at the same time as MCM?
  
• Do you run projects from other places than WCG?
  
• Do you run any projects that use OpenMP or some other multi-threading technique to utilize multiple cores?
  
• Do you suspend BOINC when you are gaming?
  

At various times, client version and various aspects of workload mix have been known to cause issues for various BOINC projects, though not necessarily in the form of hung tasks. And some users on some [non-WCG] projects have discovered that having huge numbers of cores does not necessarily mean they can successfully run huge numbers of simultaneous tasks!

I hope you find some resolution to your problem - I wonder if some system workload tuning may be of help!

Cheers - Al.

128 GB is a lot of memory, is some of your DDR4 overheating or faulty?
More RAM = more heat.
Faster RAM = more heat.

Try running Prime95 turture test and furmark at the same time for maximum heat. Any Prime95 errors or computer crashes?

Is DDR4 all unbuffered ECC (Error Correcting Code) DDR4 on compatible motherboard? or non-ECC's risk of memory corruption? As I said before, my non-ECC have some issues with hung MCM1 tasks, ARP1 invalids, and filesystem corruptions. With the switch to DDR4 unbuffered ECC it works fine for me with no more hung tasks, no more corruptions, so this looks like my old non-ECC RAM was going bad.

My AMD FX-4100 Linux, and Ryzen 2700x Win10, both now have an amazing uptime 112 days so far. Both use ECC Unbuffered RAM.

@rcthardcore

Thanks for answering my list of points - I just thought it might be worth showing the checklist in case someone found it of use(!), but your reply didn't have anything one could point a finger at!
I sometimes wonder if tasks hang up because the thread synchronization loses track of something somewhere (which may just be down to circumstances, explaining why it's not a frequently reported issue.) Over at MilkyWay they use OpenMP for a multi-threaded application and occasionally someone will post about a task that is spinning its wheels... But, again, the number of posts on that topic is far fewer than the number of tasks being completed, suggesting that it is not a very frequent issue (or that lots of people running that application never notice their system has problems?)...


If MCM1 is leaking memory, it is nowhere near as bad as OPN1; I just looked at my MCM1 tasks and all of them have working set and virtual memory size comfortably below 100MB! That's on Linux in my case, but OPN1 memory leak was happening on Linux as well as on Windows, so I think the observation is valid.

So if it is a memory use issue it's unlikely to be the same one as OPN1... Not much help, I'm afraid :-( (But I'll be interested to see where that leak turns out to be...)

All that said, if suspending (with LAIM off) and resuming a task gets it going again, at least there's a work-around for the issue...

Cheers - Al.

Probably not related to the aforementioned issue, I have four MCM tasks stuck initializing. Two have likely started before upgrading to macOS 12 (.0.1) and are stuck at a moderate time. The other two have just started and won't make it past a few seconds, before the timer resets.

stderr.txt repeatedly states:


I'm pretty certain it's related to the OS upgrade. Is there a known workaround?