-
-
Notifications
You must be signed in to change notification settings - Fork 191
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Debug #1946 #2007
base: master
Are you sure you want to change the base?
Debug #1946 #2007
Conversation
This seems to be some kind of standard script name for bootstrapping autotools. Signed-off-by: Steffen Jaeckel <[email protected]>
This reverts commit d7e46d6.
They're only used in `window.c`. Signed-off-by: Steffen Jaeckel <[email protected]>
Makefile.am
Outdated
@sed '/^# AUTO-GENERATED START/q' prof.supp > $@ | ||
@cat /usr/share/glib-2.0/valgrind/glib.supp >> $@ | ||
@wget -O- https://raw.githubusercontent.com/python/cpython/refs/tags/v`python3 --version | cut -d' ' -f2`/Misc/valgrind-python.supp >> $@ | ||
@wget -O- https://raw.githubusercontent.com/GNOME/gtk/refs/tags/`pkg-config --modversion gtk+-3.0`/gtk.supp >> $@ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one isn't working: https://raw.githubusercontent.com/GNOME/gtk/refs/tags/gtk.supp
This one is though: https://raw.githubusercontent.com/GNOME/gtk/refs/heads/main/gtk.supp
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one is though:
https://raw.githubusercontent.com/GNOME/gtk/refs/heads/main/gtk.supp
You most likely don't want the supp file for main, but for "your installed gtk version".
This one isn't working:
https://raw.githubusercontent.com/GNOME/gtk/refs/tags/gtk.supp
This is wrongly extended from
https://raw.githubusercontent.com/GNOME/gtk/refs/tags/`pkg-config --modversion gtk+-3.0`/gtk.supp
, so it seems like pkg-config --modversion gtk+-3.0
does not work for you.
Do you know where this fails for you?
What do the following commands return?
pkg-config --modversion gtk+-3.0
pkg-config --modversion gtk+-2.0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah indeed. gtk3-devel
wasn't installed. With that it works fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Researched this a bit further and removed the dependency on gtk3 + the part for gtk2, since there's no Valgrind supp file provided yet.
Seems to work also with reconnects. I'll keep this branch running for some time to see if I find more. |
This creates a "as personal as possible" Valgrind suppressions file. Signed-off-by: Steffen Jaeckel <[email protected]>
Add all elements to an array, in order to easily be able to run operations in bulk. Signed-off-by: Steffen Jaeckel <[email protected]>
`Py_Initialize()` does it since 3.7, it's a noop and deprecated since 3.9. https://docs.python.org/3/c-api/init.html#c.PyEval_InitThreads Signed-off-by: Steffen Jaeckel <[email protected]>
Signed-off-by: Steffen Jaeckel <[email protected]>
Before this change issuing `/quit` directly called `exit(0)` and did not invoke all the graceful shutdown routines. Now we first try to exit from the event loop, which includes cleaning up everything. In case the event loop is stuck for some reason, you could try to issue a second `/quit`, which will then directly call `exit(0)`. Signed-off-by: Steffen Jaeckel <[email protected]>
* Fix some linter suggestions. * Change some defines to `const` vars. * Free buffer entries in the reverse order they were allocated. Signed-off-by: Steffen Jaeckel <[email protected]>
This is a starting point while debugging #1946.
The memory usage on current develop has increased significantly since 0.14.0.
The main memory saving was done by reverting d7e46d6 which is not in 0.14.0.
I did not yet conclude on what the real problem is, but my guess is that the memory growth can only be tackled by rewriting some internal parts and we're not really leaking memory. AFAICT most memory is accounted for and is free'd on program termination.
NB: The valgrind output of a default build, executed with "our default valgrind settings" is kind of misleading. Each time a gnupg API is invoked it forks which causes the valgrind output to blow up and be hard to analyze. One way to improve the debug experience would be to disable following forks when running valgrind, another is to disable gnupg.
I've extended our default
prof.supp
by quite a bit, which must still be reviewed whether those excludes should be there or not.