Bug 246599 - math/wxmaxima: 100% CPU while idle
Summary: math/wxmaxima: 100% CPU while idle
Status: Closed Unable to Reproduce
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Lorenzo Salvadore
URL:
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2020-05-20 11:54 UTC by Peter Kien
Modified: 2022-06-01 17:17 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Kien 2020-05-20 11:54:44 UTC
Are you able to reproduce this?

I launch the program and, even though it's only waiting for input, it takes
up 100% CPU. Apart from that, everything seems normal.


I've already tried removing all related (wxMaxima, and maxima) config files.
Comment 1 Lorenzo Salvadore freebsd_committer freebsd_triage 2020-05-20 12:20:52 UTC
I am going to test it and I will tell you the results.

Thanks for reporting.
Comment 2 Lorenzo Salvadore freebsd_committer freebsd_triage 2020-05-20 14:57:52 UTC
I reproduced your issue on a machine with the following settings:
- FreeBSD 13.0-CURRENT r360656;
- ports tree r535995;
- walyand with hikari compositor.

I CC lbartoletti who recently (2020-05-17) updated wxgtk30 and thus might know something about the issue.

Peter: can you tell if the issue was already present before the wxgtk30 update?
Comment 3 Peter Kien 2020-05-21 13:36:43 UTC
(In reply to Lorenzo Salvadore from comment #2)

Versions from before -- I believe -- April didn't exhibit this problem. I can't
tell whether it's been introduced by one of the intermediate wxMaxima updates or
by wxgtk30.
Comment 4 Lorenzo Salvadore freebsd_committer freebsd_triage 2020-05-24 23:55:22 UTC
I tested wxmaxima precedent version of wxgtk30 and found the same issue.
Next step I will try is testing the precedent version of wxmaxima, then I will probably open an issue upstream.

If anyone is willing to help, using a profiler to determine the cpu consuming function would be very useful.
Comment 5 Thierry Thomas freebsd_committer freebsd_triage 2020-05-25 07:25:52 UTC
As you can see in my proposed fork in https://reviews.freebsd.org/D24959 I had to move the inline documentation from the classical $DOCSDIR to $DATADIR/$PORTVERSION/doc.

Without that, wxmaxima was looking for these docs and emitted an error message (but I did not notice abnormal CPU consumption, just a little slowness). Another possibility could be to patch every occurrence of this directory in the code, but it is easier this way.
Comment 6 Lorenzo Salvadore freebsd_committer freebsd_triage 2020-05-25 21:42:15 UTC
I tested wxmaxima 20.03.1 and determined that this version has the same bug.
I am going to try to determine what is the cpu consuming function.

(In reply to Thierry Thomas from comment #5)

Thanks Thierry, however please note that this bug is about wxmaxima, not about maxima, so I doubt the problem is caused by the documentation.
Comment 7 Lorenzo Salvadore freebsd_committer freebsd_triage 2020-05-25 21:44:05 UTC
(In reply to Thierry Thomas from comment #5)

Sorry, I read better your sentence "Without that, wxmaxima was looking for these docs and emitted an error message" and now I understood what you mean. I will check into this.
Comment 8 Lorenzo Salvadore freebsd_committer freebsd_triage 2020-05-25 22:01:10 UTC
lbartoletti:

I get lots of error message as the following:

(wxmaxima:51809): Gtk-WARNING **: 23:59:04.953: gtk_widget_size_allocate(): attempt to underallocate wxPizza's child GtkButton 0x804f166c0. Allocation is 70x28, but minimum required size is 94x34.

(wxmaxima:51809): Gtk-WARNING **: 23:59:04.953: gtk_widget_size_allocate(): attempt to underallocate wxPizza's child GtkButton 0x804f16880. Allocation is 70x28, but minimum required size is 110x34.

(wxmaxima:51809): Gtk-WARNING **: 23:59:04.953: gtk_widget_size_allocate(): attempt to underallocate wxPizza's child GtkButton 0x804f16a40. Allocation is 70x28, but minimum required size is 106x34.

Do you think this can be related to the issue? Do you have any idea for fixing it?
Thanks.
Comment 9 Lorenzo Salvadore freebsd_committer freebsd_triage 2020-05-27 23:32:42 UTC
Still no success with finding the cause of the high cpu usage, but I opened an issue upstream if anyone wants to follow it:

https://github.com/wxMaxima-developers/wxmaxima/issues/1290
Comment 10 Loïc Bartoletti freebsd_committer freebsd_triage 2020-05-28 06:12:17 UTC
(In reply to Lorenzo Salvadore from comment #2)

> I CC lbartoletti who recently (2020-05-17) updated wxgtk30 and thus might know something about the issue.

Nope sorry :/
I have not this issue with other ports using wxgtk30
Comment 11 Loïc Bartoletti freebsd_committer freebsd_triage 2020-05-28 06:15:00 UTC
(In reply to Lorenzo Salvadore from comment #8)

wxgtk uses gtk, and gtk (as qt some times) is ... verbose with this can of warning (or assert). I don't think that is related to the issue.
Comment 12 Kubilay Kocak freebsd_committer freebsd_triage 2020-06-22 07:25:11 UTC
@Peter Can we get a process trace to see what it's spinning on?

^Triage: Reset to Open
Comment 13 Loïc Bartoletti freebsd_committer freebsd_triage 2022-01-27 21:04:29 UTC
Peter Kien is the issue still present?
Comment 14 Lorenzo Salvadore freebsd_committer freebsd_triage 2022-04-22 22:03:11 UTC
Hello.

Sorry, to have dropped wxmaxima without fixing the bug, but I had to take a break from FreeBSD and I have returned only very recently. As I am planning to adopt wxmaxima again, I re-assign the bug to myself.

I am going to investigate if the issue is still present. If I cannot reproduce it anymore I am going to close the bug report, unless Peter Kien confirms that he still encounters the bug.
Comment 15 Lorenzo Salvadore freebsd_committer freebsd_triage 2022-06-01 17:17:31 UTC
I have finally tested the port and I could not reproduce the bug anymore: it must have been fixed someway.