Closed joe-h-fah closed 5 months ago
Seems to still be broken with v8.3.10 on macOS.
When a WU starts running the client spawns off a thread to follow the core log. What I think is happening here is that the first read of the log is successful but then subsequent reads are failing. But the strange thing is, none of the related code appears to have changed. So what changed on macOS that caused this to start happening from v8.3.9 on?
If I had to guess, it would be that the reader object gets released.
it might have been broken on 8.3.8 as well. I think my dev build of 8.3.7+ was working.
macOS 14.4.1 Apple silicon v8.3.5 works, v8.3.8 does not The intermediate released builds .6,.7 do not launch
I believe a bleeding edge "8.3.7+" from mid-Feb worked, but I can't find it now.
v8.3.10 with <log-domain-levels v='TailFileToLog:7'/>
does not show anything else
One possibility is that the file stream used to read the core log is getting closed. Or something has changed in how macOS handles reading past the end of a file. TailFileToLog
repeatedly reads past the end, waiting for more data.
This is really strange. I added some more error checking and a debug line to TailFileToLog
. It sees no errors, i.e. the file stream appears to be fine. But, it also does not see any new data. It just churns along happily with out reading any more data after the first read. This code hadn't changed for years before this bug started to occur. It doesn't make much sense. I wonder if it was caused by a compiler or library upgrade.
I believe the build machine has been using the same compiler for many months. I don’t remember the last system update. I think it’s still behind the latest macOS 12.
Is this bug not occurring on any other platform?
Definitely not on Linux. And @Hou5e's logs show it working correctly on Windows. Very strange. Maybe there's a bug somewhere else that's corrupting memory and this is the side-effect.
The progress jumps to an integer percent without it being logged. Does Unit get actual progress from reading the core output? If so, that would indicate the Unit is processing the core output; it just doesn't get echoed to the log.
The client reads the progress info from wuinfo_01.dat
which the core writes to periodically. It's ugly but that's how it's worked since before I started with F@H.
What I'd really like to do is have the core read from stdin and write to stdout and the client open those streams as pipes when it spawns the core. Then we could do away with reading back the log file, reading wuinfo_01.dat
or wudata_01.dat
, etc. But this would require new cores that supported both the new interface and the old one.
I finally figured this out. Previously we were using a custom implementation of std::fstream
in C!. I recently simplified things and went back to using the built-in std::fstream
for most cases. Unfortunately, there is some inconsistent behavior between libstdc++ implementations. Specifically, you must call std::istream::seekg()
on some implementations in order to fully reset the stream after you've hit EOF. So even though the TailFileToLog
code hadn't changed it now needs the std::istream::seekg()
call to work correctly.
The fix is in the upcoming v8.3.11.
Obscure bug. Makes me think of the corollary "The nice thing about standards is there are so many implementations to choose from."
I can confirm this is working on macOS 14.4.1 intel and Apple silicon.
Just updated my machines to v8.3.11, now it just shows "No matching log lines" in the log window of the web control. This on an Intel macOS 10.13.6 and a 13.6.7 Apple silicon machine.
Is the client crash-looping when you try to fold? Beware rapid bogus failed WU uploads killing your bonus, among other things. You can see crash reports in the Console.app, of course.
The client is folding just fine and WUs have uploaded from both systems. This version appears to have fixed the entries getting into the log file itself, percent progress messages now show up there. But maybe the fix is now blocking the web client from reading the log. Can start a new report in the web control issues if that is needed.
Is that the release or debug build?
The release build.
Running the alpha v8.3.9 on two different Mac systems with OS versions 13.6.3 and 10.13.6. Client log records the client and WU startup messages, but after the starting at n% message dos not show any progress messages. Just records when the WU completes, the upload, and download of a new WU and that WU's startup.
Perhaps related to this, the rollover to a new log coincided with a new WU starting, not midnight UTC.
Log from one system, similar log on the other system: