Message boards :
Questions and problems :
New Boinc version - very sparse event log
Message board moderation
Author | Message |
---|---|
Send message Joined: 29 Aug 05 Posts: 15483 |
Found it - options, event log options, tick "app msg send".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 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 |
Send message Joined: 5 Oct 06 Posts: 5082 |
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? |
Send message Joined: 29 Aug 05 Posts: 15483 |
Not sure what you ask? The hard-coded flags aren't (normally) run from cc_config.xml, because BOINC doesn't come with one. |
Send message Joined: 5 Oct 06 Posts: 5082 |
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. |
Send message Joined: 29 Aug 05 Posts: 15483 |
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:\BOINCMissing 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. |
Send message Joined: 29 Aug 05 Posts: 15483 |
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 |
Send message Joined: 5 Oct 06 Posts: 5082 |
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 filesAfter 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 secondsThat'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 secondsSo, 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. |
Send message Joined: 5 Oct 06 Posts: 5082 |
Missing the log flags line.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? |
Send message Joined: 5 Oct 06 Posts: 5082 |
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. |
Send message Joined: 29 Aug 05 Posts: 15483 |
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. |
Send message Joined: 5 Oct 06 Posts: 5082 |
|
Send message Joined: 5 Oct 06 Posts: 5082 |
OK, I've been staring at this - what's wrong with it (except that it doesn't work)? The key words seem to be static, const*, and this.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 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. |
Send message Joined: 5 Oct 06 Posts: 5082 |
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/resumedoes at least generate 16/04/2020 11:13:02 | | log flags: file_xfer, sched_ops, taskDare I suggest it? |
Send message Joined: 29 Aug 05 Posts: 15483 |
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 = xOr 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. |
Send message Joined: 5 Oct 06 Posts: 5082 |
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. |
Send message Joined: 25 May 09 Posts: 1284 |
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. |
Send message Joined: 5 Oct 06 Posts: 5082 |
|
Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License,
Version 1.2 or any later version published by the Free Software Foundation.