Found it - options, event log options, tick "app msg send".

14/04/2020 2:39:17 PM | | log flags: file_xfer, sched_ops, task, app_msg_send1

No, it's not app msg send, as that shows the shared memory messages sent to the science applications. It's the three before that in the above line, file_xfer, sched_ops and task. We've had a report in on the Alpha list (and project forums) that several people see this behaviour on their BOINC start, where the three hard-coded debug flags don't start up.

Else a startup shows something like this:

14/04/2020 16:41:16 | | Starting BOINC client version 7.16.5 for windows_x86_64
14/04/2020 16:41:16 | | log flags: file_xfer, sched_ops, task, checkpoint_debug, coproc_debug, sched_op_debug
14/04/2020 16:41:16 | | Libraries: libcurl/7.47.1 OpenSSL/1.0.2s zlib/1.2.8

By going to the Event Log Options menu you only made sure that cc_config.xml was written and that these three flags were activated.
You can go back and uncheck app_msg_send

---

By going to the Event Log Options menu you only made sure that cc_config.xml was written ...

... and is readable by the new client?

Not sure what you ask?
The hard-coded flags aren't (normally) run from cc_config.xml, because BOINC doesn't come with one.

I don't think we've tracked down the cause of the problem enough, yet, so I'm just free-associating for places to look.

New install, or upgrade?
If upgrade, with or without cc_config.xml?
If cc_config.xml, no flags, standard flags, or custom flags?

BOINC started by installer, at machine start, or by user?

And so on.

I had a new install on my system and I never saw the problem but then I wasn't looking at the messages. But let me test. I renamed my cc_config.xml to cc_config.xml.bak and exited & restarted BOINC. That seems to do it:

14/04/2020 18:13:39 |  | cc_config.xml not found - using defaults
14/04/2020 18:13:39 |  | Starting BOINC client version 7.16.5 for windows_x86_64
14/04/2020 18:13:39 |  | Libraries: libcurl/7.47.1 OpenSSL/1.0.2s zlib/1.2.8
14/04/2020 18:13:39 |  | Data directory: G:\BOINC

Missing the log flags line.

So what last change did we do to the log_flags.cpp?
Edit: https://github.com/BOINC/boinc/commit/a79d60b8891237e011bdaad3bd1a7c1572e2f3b7 changes to make the file sizes for stderrdae and stdoutdae doubles, not int

I was looking earlier in the source code where we start the 3 hard coded flags. Didn't find it so quickly.

They're started from lib/cc_config.cpp

void LOG_FLAGS::init() {
    static const LOG_FLAGS x;
    *this = x;

    // on by default (others are off by default)
    //
    task = true;
    file_xfer = true;
    sched_ops = true;
}

The only thing I see that may be strange is that we add the cc_config.h header twice.
https://github.com/BOINC/boinc/blob/3ed2b089c81378e7dbe6f56556424bdb94081105/lib/cc_config.cpp

---

Tried doing the same thing, on my new testbed:

15/04/2020 16:00:26 |  | Processor: 4 GenuineIntel Intel(R) Celeron(R) CPU J3455 @ 1.50GHz [Family 6 Model 92 Stepping 9]

- it need rebooting to apply patches, so I renamed cc_config.xml

Same missing log flags line, and also missing 'Initialization completed', which should come after

15/04/2020 16:00:26 |  | Setting up GUI RPC socket
15/04/2020 16:00:26 |  | Checking presence of 76 project files

After doing benchmarks, there was only one line from the first scheduler request

15/04/2020 16:00:58 |  | 4985 integer MIPS (Dhrystone) per CPU
15/04/2020 16:13:57 | NumberFields@home | Project requested delay of 61 seconds

That's 'new this version', and I had a hand in requesting it - we can check the differences.

Then I opened and saved the Event Log flag chooser, without making any changes. The next scheduler request was complete.

15/04/2020 16:19:53 |  | Re-reading cc_config.xml
15/04/2020 16:19:53 |  | log flags: file_xfer, sched_ops, task
15/04/2020 16:30:04 | NumberFields@home | Sending scheduler request: To fetch work.
15/04/2020 16:30:04 | NumberFields@home | Reporting 1 completed tasks
15/04/2020 16:30:04 | NumberFields@home | Requesting new tasks for CPU
15/04/2020 16:30:06 | NumberFields@home | Scheduler request completed: got 1 new tasks
15/04/2020 16:30:06 | NumberFields@home | Project requested delay of 61 seconds

So, what went wrong?

I don't think it the double reference to cc_config.h header - both references have been there for 8 years. More likely

client: get rid of the use of memset() to initialize structs to zero. (5 months ago)
client: changes to GUI RPC file fetch mechanism (8 months ago)
client: add <ignore_tty> config file option (Unix) (14 months ago)

All touched this file, but I think that's a decreasing order of likelihood, as well as age. I'll start looking from the top.

Missing the log flags line.

I was looking earlier in the source code where we start the 3 hard coded flags. Didn't find it so quickly.

This is the line which should print the missing flags:

https://github.com/BOINC/boinc/blob/master/client/client_state.cpp#L477

Now, where's that log_flags.show() function?

OK, I think this might be the problem. https://github.com/BOINC/boinc/blob/master/lib/cc_config.cpp#L42

void LOG_FLAGS::init() {
    static const LOG_FLAGS x;
    *this = x;

    // on by default (others are off by default)
    //
    task = true;
    file_xfer = true;
    sched_ops = true;
}

In v7.14.2, it was https://github.com/BOINC/boinc/blob/client_release/7/7.14/lib/cc_config.cpp#L41

LOG_FLAGS::LOG_FLAGS() {
    init();
}

void LOG_FLAGS::init() {
    memset(this, 0, sizeof(LOG_FLAGS));
    // on by default (others are off by default)
    //
    task = true;
    file_xfer = true;
    sched_ops = true;
}

but new lines like "*this = x;" are meaningless to me - horrible language.

I saw that yesterday, but my understanding of C++ isn't good enough to see if that was a problem.

Edit: it came across on me as a temporary thing, as if something had to be added here at a later time. But apparently it compiled correctly.

---

Well, I've decided it's close enough to a smoking gun (code change in November 2019) to open #3606. We'll see what happens.

And I need to change my own #3402 to put the scheduler delay under sched_op control (but not sched_op_debug, as it was).

OK, I've been staring at this - what's wrong with it (except that it doesn't work)?

void LOG_FLAGS::init() {
    static const LOG_FLAGS x;
    *this = x;

    // on by default (others are off by default)
    //
    task = true;
    file_xfer = true;
    sched_ops = true;
}

The key words seem to be static, const*, and this.

The problem is to create and initialise a structure of variables (not constants), and to set the initial values of three of them. What could be simpler?

'static' I understand - it's universal, can be used anywhere in the program, and the values are the same everywhere you look at them.

'this' seems fine: we could be explicit and say 'this->task' - it compiles, but doesn't change the behaviour.

So we're stuck with 'const'. Why is that there? Again, taking it out compiles, but doesn't change the behaviour.


*const is badly described in cppreference, but the only other reference is to const as a cv type qualifier.

But this, on the other hand,

struct LOG_FLAGS {
    // If you add anything, you must add it to parse() and write()

    // on by default; intended for all users
    //
    bool file_xfer = true;
        // file transfer start and finish
    bool sched_ops = true;
        // interactions with schedulers
    bool task = true;
        // task start and finish, and suspend/resume

does at least generate

16/04/2020 11:13:02 |  | log flags: file_xfer, sched_ops, task

Dare I suggest it?

OK, I've been staring at this - what's wrong with it (except that it doesn't work)?

As far as I know, from all my different programming languages, X always needs a value and it doesn't get it here.

So either it's:

x = 6

*this->x = x

Or x somehow has to get the value 'true', but not what it's doing in that code.

What was wrong with the v7.14.2 code? At least that worked.

---

Some people don't like 'memset' - eradicating that was the stated reason for the change.

I tried setting x.task = true - the syntax passed, but x.task was read-only.

Very strange as memset has been around for years and is very well understood...
The replacement of memset, which is very clear and precise, with the arcane *this construct does not always result in the same pointers being created and may depend on the exact version of compiler in use (on one project I was involved in *this was prohibited due to its lack of consistency). A fine example of if it ain't broke don't fix it unless you have a very good reason to fix it, and it ain't broke so don't fix it.

Well, the trail is #3245, #3363, #3364, with the final one being responsible for this problem. Enter the jungle at your peril (and remember your PPE).