All versions of Manager "crash" after message "CPU busy"

[debianmain1]

I'm starting to pull my hair out over this.....I have been building off of the Main for about a year now & for the last couple of months I'll come back to the Manager & it has "crashed". When I start in a terminal I will see that this almost always is right after I see "[---] Suspending computation - CPU is busy The next line will be: [---] Resuming computation. I run BOINC from its own dedicated drive & my build is done with:

cd '/media/Boinc' git clone https://github.com/BOINC/boinc boinc cd '/media/Boinc/boinc' ./_autosetup ./configure --disable-server --enable-client --enable-debug CXXFLAGS="-O3 " make cd packages/generic/sea/ make

Then, I copy/paste the contents of /media/Boinc/BOINC/packages/generic/sea/BOINC into /BOINC to maintain my data. I start BOINC with '/media/Boinc/BOINC/run_client' in the terminal, and then after I see the output, I start the manager.

This has "seemed" to work very well, but with the variable "crashing", I'm not so sure. Is there a "better practice" way to do this? Are there any thoughts that would make it easier to debug? I'm not getting anything helpful even with the "debug" flag set. I have tried building the current stable version, the updated version 8 & the current test version all with the same results.

[davidpanderson]

I would say "run the Manager under gdb and see where it's crashing",
but this doesn't seem to work - the executable doesn't have symbols or something.
We'll look into this.

[AenBleidd]

@davidpanderson, do you have this issue with manager only or with the client as well?
I checked our CI builds, and even if they are not run with the --enable-debug flag all of them still contain all the debug symbols, and when simply running the application in the gdb, I see the symbols.
E.g.

(gdb) where
#0  0x00007ffff7dd74cd in __GI___poll (fds=0x5555580857e0, nfds=3, timeout=98) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x0000555556b27757 in g_main_context_iterate_unlocked.isra ()
#2  0x0000555556b2830f in g_main_loop_run ()
#3  0x000055555618820d in gtk_main ()
#4  0x0000555555e81975 in wxGUIEventLoop::DoRun() ()
#5  0x0000555555fa3f41 in wxEventLoopBase::Run() ()
#6  0x0000555555ed3279 in wxDialog::ShowModal() ()
#7  0x0000555555c9460a in wxWizardEx::RunWizard (firstPage=<optimized out>, this=0x5555583633f0) at wizardex.cpp:603
#8  wxWizardEx::RunWizard (this=0x5555583633f0, firstPage=<optimized out>) at wizardex.cpp:594
#9  0x0000555555c1b9a3 in CSimpleFrame::OnConnect (this=0x555557fe0090) at sg_BoincSimpleFrame.cpp:896
#10 0x0000555556065f52 in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) ()
#11 0x00005555560660b3 in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) ()
#12 0x00005555560664bd in wxEvtHandler::TryHereOnly(wxEvent&) ()
#13 0x000055555606653e in wxEvtHandler::ProcessEventLocally(wxEvent&) ()
#14 0x00005555560665e9 in wxEvtHandler::ProcessEvent(wxEvent&) ()
#15 0x0000555556066f5b in wxEvtHandler::SafelyProcessEvent(wxEvent&) ()
#16 0x0000555556067022 in wxEvtHandler::ProcessPendingEvents() ()
#17 0x0000555555f6abea in wxAppConsoleBase::ProcessPendingEvents() ()
#18 0x0000555555e6f63e in wxApp::DoIdle() ()
#19 0x0000555555e6f707 in wxapp_idle_callback ()
#20 0x0000555556b24349 in g_main_dispatch ()
#21 0x0000555556b27818 in g_main_context_iterate_unlocked.isra ()
#22 0x0000555556b2830f in g_main_loop_run ()
#23 0x000055555618820d in gtk_main ()
#24 0x0000555555e81975 in wxGUIEventLoop::DoRun() ()
#25 0x0000555555fa3f41 in wxEventLoopBase::Run() ()
#26 0x0000555555f6b9bf in wxAppConsoleBase::OnRun() ()
#27 0x0000555555ff3388 in wxEntry(int&, wchar_t**) ()
#28 0x0000555555b0ada6 in main (argc=<optimized out>, argv=<optimized out>) at BOINCGUIApp.cpp:61

[davidpanderson]

I was seeing this issue with the client (my Linux system is headless)

[AenBleidd]

Let's check this on the next call.

[CharlieFenton]

What operating system is this under? Windows 10? Windows 11? MacOS. Linux Debian? etc.

[AenBleidd]

I'd say it's Linux.
I'll check for correct debug build during next few days

[debianmain1]

Sorry about not including the extra info...

dean@ASUS-Z790
OS: EndeavourOS Linux x86_64
Kernel: 6.13.1-zen1-1.1-zen
Uptime: 3 days, 1 hour, 20 mins
Packages: 1528 (pacman)
Shell: bash 5.2.37
Resolution: 3440x1440
DE: GNOME 47.4
WM: Mutter
WM Theme: Adwaita
Theme: Adwaita-dark [GTK2/3]
Icons: Colloid-Purple-Dracula-Dark [GTK2/3]
Terminal: gnome-terminal
CPU: 13th Gen Intel i7-13700KF (16) @ 5.300GHz
GPU: Intel Battlemage G21 [Arc B580]
Memory: 10991MiB / 31848MiB

Anything else needed?

[CharlieFenton]

This might be a debugging breakpoint built into wxWidgets. We cleaned up a lot of harmless incorrect arguments to wxSizers some time back, which trigger a breakpoint and warning dialog in debug builds but not in release builds. But if not run under a debug, they cause the executable to crash.

Note that the crash is in wxWizardex which I believe is called from CSimpleFrame when there are no projects attached. The backtrace has CSimpleFrame::OnConnect (this=0x555557fe0090) at sg_BoincSimpleFrame.cpp:896 which is pWizard->Run( and is called based on the condition if ((0 >= pDoc->GetProjectCount()) && !status.disallow_attach) { on line 884 of sg_BoincSimpeFrame.cpp.

I think this may have nothing to do with "CPU is busy." I suspect if you run it under a debugger you will see a warning message from wxWidgets.

[AenBleidd]

This is not a crash in my case, I just put the debuggee (BOINC Manager) on pause to check the stack and to ensure that I have the symbols.

[debianmain1]

I'm going to run boincmgr with gdb & debuginfod enabled & just let it run tonight...I'll come back to it tomorrow morning to see what happened.

[debianmain1]

Ok...I ran boincmgr as outlined above & when I got back to it after 9 hours it had crashed---no input, just the dialog to exit the manager. No information in the gdb session, just notifications of threads.

I have started boinc in the same way as above & let it start then started boincmgr. It is currently running & I will report if there are any interesting lines in the output.

[AenBleidd]

Are you sure it's Manager that crashed? Assuming that you see the dialog to exit manager, maybe it's the client that crashed but Manager continues running?

[debianmain1]

Well....when I open the manager, all the information in the window is "frozen" (if I go to any other tab---that tab is blank. I normally have the "task" tab open) & if I click in any area in any tab I get the "exit Manager" dialog....at the same time if I look at the terminal I started boinc in, I will see a timestamp sometime in the past with the "CPU busy"/"Resuming Computation" on the last 2 lines.

Right now I'm running the client with gdb to see if I can capture anything more. As this behavior is non-determinate as to when it "crashes"...this may not show again for several hours.

[debianmain1]

OK...another non-answer. Once again, I changed tabs in the manager & got the "exit Manager" dialog. gdb run is not very informative.

10-Feb-2025 11:11:48 [NFS@Home] Started upload of S2p1124_3565236_0_r506209701_0
[New Thread 0x7ffff5c7e6c0 (LWP 1016125)]
[Thread 0x7ffff5c7e6c0 (LWP 1016125) exited]
10-Feb-2025 11:11:50 [NFS@Home] Finished upload of S2p1124_3565236_0_r506209701_0 (116087 bytes)
10-Feb-2025 11:12:07 [---] Resuming computation
10-Feb-2025 11:13:16 [NFS@Home] Computation for task S2p1124_3564060_0 finished
[Detaching after fork from child process 1017878]
10-Feb-2025 11:13:16 [Amicable Numbers] Starting task amicable_10_21_15655_1738885201.673695_60_0
10-Feb-2025 11:13:17 [---] Suspending computation - CPU is busy
10-Feb-2025 11:13:18 [NFS@Home] Started upload of S2p1124_3564060_0_r922362061_0
[New Thread 0x7ffff5c7e6c0 (LWP 1017900)]
[Thread 0x7ffff5c7e6c0 (LWP 1017900) exited]
10-Feb-2025 11:13:20 [NFS@Home] Finished upload of S2p1124_3564060_0_r922362061_0 (101245 bytes)
10-Feb-2025 11:13:37 [---] Resuming computation

At that point, the file ended.

[debianmain1]

Hmmmm....OK. So far it's not looking too bad...I'm seeing an occasional spike to 80c, but it is looking more around 65c. I don't hyperthread, so are you thinking more about me using 4~6 cores at 100%?

[debianmain1]

And it won't allow nothing in the field...so I ran with 100%.....

[AenBleidd]

It's completely up to you and your hardware. I can't recommend any particular value to be set.
I have these values that are comfortable for me, but since you have different hardware, you should play with the settings to find the best combination for you.

[debianmain1]

Sounds good....I don't want to use the "economy" cores, so 8 looks like the max number. So far I've seen the "CPU busy" twice in the last 1/2 hour with no problems....so I'll monitor it further.

[debianmain1]

I also removed the "suspend when" percentages as per yours & see how that goes.....

[debianmain1]

Full run here:
output.zip

[debianmain1]

More info here:

[debianmain1]

Normally all performance cores will be at 5300 (turbo)....the only time that they drop to 4700 is when Amicable Numbers is using all 8. The "crash" I'm talking about happens with any mix of jobs...I'm currently doing Einstein, NFS, yoyo, SRBase, Amicable Numbers & NumberFields.

[debianmain1]

OK...still "crashed" with a slight change even with what was done above. Manager "frozen" and when I changed tabs I got the "exit manager" dialog. The change is no "CPU busy" and "Resuming computation" notifications in the terminal--just a notification that an upload was done.....The time stamp was 20 minutes ago....

[debianmain1]

I've addressed the "elephant in the room" & upgraded to an i7-14700KF.....still having the same problems. Any updates?

[AenBleidd]

I can't reproduce this.
I will think about the information I need from you and the way to get it to proceed with this.

[debianmain1]

Thank You.