Cyrix126 / gupaxx

Fork of Gupax integrating the XMRvsBeast Raffle
https://xmrvsbeast.com
GNU General Public License v3.0
21 stars 3 forks source link

Freeze windows 10 #12

Closed anon-erpk closed 2 months ago

anon-erpk commented 3 months ago
          @anon-erpk @seatsea Can you tell me if new lines in the XvB tab console appears every minutes instead of every ten minutes when the UI is freezed or does it freeze also without this issue ?

Originally posted by @Cyrix126 in https://github.com/Cyrix126/gupaxx/issues/6#issuecomment-2119245004

I'm not able to see if that's the problem, when the UI freezes I'm not able to check any tab, in 1.0 and 1.1 releases I had the "not responding" error, in 1.2 the UI just freezes, and everything stops (p2pool, xmrig, proxy and XvB), I have to Force Close all the process tree to be able to restart gupaxx.

I'm Windows 10

Cyrix126 commented 3 months ago

Since 1.1.1 Gupaxx should lower the priority of xmrig which was taking all the cpu time, letting Gupaxx to crash. At least it solved the issue in the VM of W10 I was testing. Can you check in your task manager if xmrig start with a lower priority ? and also do you still have the crash if you put Gupaxx with a higher priority ?

anon-erpk commented 3 months ago

no, I'm lowering xmrig priority by myself, now I will test Gupaxx with a higher priority.

edit: even with this priority configuration, it freezes after sometime, I'm not able to see if it's the XvB algo

anon-erpk commented 3 months ago

I'm sorry for chainposting , but I need to update this situation:

yesterday I tried again to change the processes priority xmrig was on Idle, and GUPAXX on Above Normal, it was running until now with almost no problems, the UI was not maximized (I was doing it before), p2pool, xmrig, and proxy were still running, but the XvB tab was "yellow" but it never finished to restart, and I was not able to do it manually, the buttons were all disabled.

Cyrix126 commented 3 months ago

I'm sorry for chainposting

I prefer to have updates, no worries. The maximization of the UI should not make a difference. What you are describing however appears to be a different issue. Yellow means the process is in the middle of a start. If it is not getting to a failed state or alive after a few seconds, then it is a bug where a situation has not been taken into account. Did it get into yellow after a while ? what was saying the console of XvB ? does the rest of the UI were responsive ?

anon-erpk commented 3 months ago

Ok, new update, today I was able to see the moment when the UI freezes, and, unfortunately, is just it, I had to restart gupaxx sometimes today, due the freezing, sometimes the XvB algo doesn't start (it stays yellow and don't get triggered when p2pool finishes to sync), sometimes it just freeze all UI interface, XvB console messages are normal, no errors, just pointing to p2pool or donating.

Is there a way to get logs to investigate what is happening?

Cyrix126 commented 3 months ago

Is there a way to get logs to investigate what is happening?

The output in the terminal should show the logs, but it seems to not be working on Windows. I made a commit to add a command line option --logfile, that will simply write the output to a file in the directory of Gupaxx. You can download the binary on the github actions

Do you have freezes even if the priority of xmrig is lower and the one of gupaxx is higher ? you didn't mentioned if you changed them on your last message. It is expected to freeze if the priority of xmrig is not lower. Gupaxx should set it automatically, so if it's not, that's the first issue to fix.

anon-erpk commented 3 months ago

Yesterday I had 3 or 4 freezes during the first hours of the morning when I wrote the last update, in a time spam of 20 minutes, after that, gupaxx is running with no issues until now,but i'll run this binary to see if something shows up on the logs

Cyrix126 commented 3 months ago

Yesterday I had 3 or 4 freezes during the first hours of the morning when I wrote the last update, in a time spam of 20 minute

Yes but was it with xmrig set at lower priority ?

anon-erpk commented 3 months ago

Yesterday I had 3 or 4 freezes during the first hours of the morning when I wrote the last update, in a time spam of 20 minute

Yes but was it with xmrig set at lower priority ?

No, I had no issues since my last post, BUT i had to change the priority by myself (with process explorer (not task manager), I put xmrig at the lowest priority), aaand... everything is running smooth since then.

Cyrix126 commented 3 months ago

ok thanks, so apparently this is not active in your situation. I'll check with the VM. https://github.com/Cyrix126/gupaxx/blob/0865fe2ef2ad37282f8bceef05927a4e5ddabe7a/src/helper/xrig/xmrig.rs#L472-L485

anon-erpk commented 3 months ago

Hey, I forgot to mention, after the first freeze, the program is not starting again (some configuration file maybe?), since then, I have to run it in compatibility mode (win7 or 8).

Cyrix126 commented 2 months ago

Can you try https://github.com/Cyrix126/gupaxx/actions/runs/9991285994 ? there should not be any freeze anymore since the command to lower xmrig priority is now working.

iamdeka commented 2 months ago

I have the same issue of Gupaxx freezing and not responding after a while on the 1.2.0 release, but this doesn't happen using the gupaxx_b.exe binary from the action and i currently have 2 days of uptime on it Windows 11 24H2

Cyrix126 commented 2 months ago

I have the same issue of Gupaxx freezing and not responding after a while on the 1.2.0 release, but this doesn't happen using the gupaxx_b.exe binary from the action and i currently have 2 days of uptime on it Windows 11 24H2

The only difference between the two are that _b will update bundled binairies by default.

I'll close the issue after the 1.3.0 release, except if you tell me you have a freeze with latest action binary.

iamdeka commented 2 months ago

Running on the same binary with 3 days of uptime now. It seems to be fixed

Cyrix126 commented 2 months ago

fixed in 1.3.0