After a few minutes editing, Geany freezes with cpu usage increasing to 100%. Force quit required. System: Linux Mint 22 geany 2.0 (built on 2024-03-31 with GTK 3.24.41, GLib 2.80.0) libgtk-3-0t64:amd64 3.24.41-4ubuntu1.1 amd64 installed
WFM More details on what you are doing needed. Disable all plugins and see what happens (if Geany locks up immediately edit `session.conf` with an other editor and empty the `active_plugins=` list)
Thanks for the very quick reply. I disabled plugin (only one: splitwindows) and so far no freezing. Many thanks!
Spoke too soon it happened again, though I could type for longer (20min)
Do you use Wayland by chance? Sounds a bit similar to https://github.com/geany/geany/issues/2737 or https://github.com/geany/geany/issues/3447.
If you are using a Wayland session its likely that GTK chooses Xwayland, try `GDK_BACKEND=wayland geany` so it uses wayland without Xwayland in between.
No, no wayland. Mint/Cinnamon still use X
No, no wayland. Mint/Cinnamon still use X
Right right, I knew that ;-S
Weird, as I said WFM. All I can suggest is to run geany under gdb and when it hangs ^C in gdb and get a backtrace.
OK. Thanks. It seems a lot better after disabling the plugin. Let's see if it freezes when using the debugger!
Closed #3944 as completed.
OK. Thanks. It seems a lot better after disabling the plugin. Let's see if it freezes when using the debugger!
Finally got a freeze while using the debugger but ctrl-C gave only the following: Thread 1 "geany" received signal SIGINT, Interrupt. 0x00007ffff7db4786 in ?? () from /lib/x86_64-linux-gnu/libgeany.so.0
Did you ask for a backtrace as I [suggested](https://github.com/geany/geany/issues/3944#issuecomment-2342394310)?
Ah, that's more like it! #0 0x00007ffff7cd158c in ??? () at /lib/x86_64-linux-gnu/libgeany.so.0 #1 0x00007ffff7d41f49 in ??? () at /lib/x86_64-linux-gnu/libgeany.so.0 #2 0x00007ffff7d46b69 in ??? () at /lib/x86_64-linux-gnu/libgeany.so.0 #3 0x00007ffff7db2a65 in ??? () at /lib/x86_64-linux-gnu/libgeany.so.0 #4 0x00007ffff7dbb72d in ??? () at /lib/x86_64-linux-gnu/libgeany.so.0 #5 0x00007ffff7d80455 in ??? () at /lib/x86_64-linux-gnu/libgeany.so.0 #6 0x00007ffff7caca3a in ??? () at /lib/x86_64-linux-gnu/libgeany.so.0 #7 0x00007ffff7cba529 in ??? () at /lib/x86_64-linux-gnu/libgeany.so.0 #8 0x00007ffff7cc92d1 in ??? () at /lib/x86_64-linux-gnu/libgeany.so.0 #9 0x00007ffff7c7d8a5 in ??? () at /lib/x86_64-linux-gnu/libgeany.so.0 #10 0x00007ffff5feeb16 in ??? () at /lib/x86_64-linux-gnu/libffi.so.8 #11 0x00007ffff5feb3ef in ??? () at /lib/x86_64-linux-gnu/libffi.so.8 #12 0x00007ffff5fee0be in ffi_call () at /lib/x86_64-linux-gnu/libffi.so.8 #13 0x00007ffff6ca52d3 in g_cclosure_marshal_generic_va () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #14 0x00007ffff6cbe6bd in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #15 0x00007ffff6cbea98 in g_signal_emit_by_name () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #16 0x00007ffff7c75e42 in ??? () at /lib/x86_64-linux-gnu/libgeany.so.0 #17 0x00007ffff6c9e2fa in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #18 0x00007ffff6ccd90c in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #19 0x00007ffff6cbe591 in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #20 0x00007ffff6cbe7c1 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #21 0x00007ffff6cbe883 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #22 0x00007ffff7d7c147 in ??? () at /lib/x86_64-linux-gnu/libgeany.so.0 #23 0x00007ffff7dc8f8f in ??? () at /lib/x86_64-linux-gnu/libgeany.so.0 #24 0x00007ffff7dd1b91 in ??? () at /lib/x86_64-linux-gnu/libgeany.so.0 #25 0x00007ffff7d82c1b in ??? () at /lib/x86_64-linux-gnu/libgeany.so.0
Missed some: #25 0x00007ffff7d82c1b in ??? () at /lib/x86_64-linux-gnu/libgeany.so.0 --Type <RET> for more, q to quit, c to continue without paging--c #26 0x00007ffff7b38c6d in ??? () at /lib/x86_64-linux-gnu/libgdk-3.so.0 #27 0x00007ffff6b9d48e in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #28 0x00007ffff6bfc717 in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #29 0x00007ffff6b9df77 in g_main_loop_run () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #30 0x00007ffff71feb45 in gtk_main () at /lib/x86_64-linux-gnu/libgtk-3.so.0 #31 0x00007ffff7c9ecfe in main_lib () at /lib/x86_64-linux-gnu/libgeany.so.0 #32 0x00007ffff782a1ca in __libc_start_call_main (main=0x555555555060, main@entry=<error reading variable: Cannot access memory at address 0x7fffffffdd58>, argc=1, argc@entry=<error reading variable: Cannot access memory at address 0x7fffffffdc70>, argv=0x7fffffffddb8, argv@entry=<error reading variable: Cannot access memory at address 0x7fffffffdc68>) at ../sysdeps/nptl/libc_start_call_main.h:58 #33 0x00007ffff782a28b in __libc_start_main_impl (main=Python Exception <class 'gdb.MemoryError'>: Cannot access memory at address 0x7fffffffdd58 #34 0x0000555555555095 in ??? ()
Reopened #3944.
Well thats good, but unfortunately nothing has debug symbols except a few parts of libgobject so we can tell it is in Geany (not libraries or other) but we can't tell where it is in Geany or what its doing, sigh.
Because so far AFAIK nobody else has reproduced the problem except you, all we can do is ask for your help. I don't suppose here is any chance you could build Geany from git (which will have symbols)?
I don't suppose here is any chance you could build Geany from git (which will have symbols)?
Maybe it's enough to install the "geany-dbgsym" package if it is available (and/or similarly named).
Ahh, yeah, @DavParc you need to enable the debug symbols repository in the LM menu `Administration->Software Sources` then the `geany-dbgsym` is available to install.
Ok. Done that. Now we wait until it freezes again
OK. Some freezes today, though they would resolve if I waited long enough. Here's the gdb backtrace. Hope it is useful!
#0 __strncpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S:1126 #1 0x00007ffff6bb85d9 in g_strndup () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007ffff7ac2f18 in pango_layout_set_text () at /lib/x86_64-linux-gnu/libpango-1.0.so.0 #3 0x00007ffff7d794df in (anonymous namespace)::LayoutSetText (text=Python Exception <class 'gdb.error'>: value has been optimized out , layout=0x5555581fe3b0) at /usr/include/c++/13/string_view:289 #4 (anonymous namespace)::ClusterIterator::ClusterIterator (text=Python Exception <class 'gdb.error'>: value has been optimized out , layout=0x5555581fe3b0, this=0x7fffffffad50) at ../scintilla/gtk/PlatGTK.cxx:837 #5 Scintilla::SurfaceImpl::MeasureWidthsUTF8 (this=<optimized out>, font_=0x55555871ef40, text=Python Exception <class 'gdb.error'>: value has been optimized out , positions=0x7fffdfe0cac0) at ../scintilla/gtk/PlatGTK.cxx:1079 #6 0x00007ffff7df7106 in PositionCache::MeasureWidths (this=0x5555577d29a0, surface=<optimized out>, vstyle=<optimized out>, styleNumber=4, unicode=true, sv="728333", positions=0x7fffdfe0cac0, needsLocking=false) at ../scintilla/src/PositionCache.cxx:1169 #7 0x00007ffff7de0284 in (anonymous namespace)::LayoutSegments (pCache=<optimized out>, surface=0x5555587475f0, vstyle=..., ll=0x5555586d9960, segments=std::vector of length 1499999, capacity 2097152 = {...}, nextIndex=<optimized out>, textUnicode=true, multiThreaded=false) at ../scintilla/src/EditView.cxx:376 #8 0x00007ffff7de8c23 in operator() (__closure=<optimized out>) at ../scintilla/src/EditView.cxx:513 #9 std::__invoke_impl<void, Scintilla::Internal::EditView::LayoutLine(const Scintilla::Internal::EditModel&, Scintilla::Internal::Surface*, const Scintilla::Internal::ViewStyle&, Scintilla::Internal::LineLayout*, int, bool)::<lambda()> > (__f=<optimized out>) at /usr/include/c++/13/bits/invoke.h:61 #10 std::__invoke<Scintilla::Internal::EditView::LayoutLine(const Scintilla::Internal::EditModel&, Scintilla::Internal::Surface*, const Scintilla::Internal::ViewStyle&, Scintilla::Internal::LineLayout*, int, bool)::<lambda()> > (__fn=<optimized out>) at /usr/include/c++/13/bits/invoke.h:96 #11 std::thread::_Invoker<std::tuple<Scintilla::Internal::EditView::LayoutLine(const Scintilla::Internal::EditModel&, Scintilla::Internal::Surface*, const Scintilla::Internal::ViewStyle&, Scintilla::Internal::LineLayout*, int, bool)::<lambda()> > >::_M_invok--Type <RET> for more, q to quit, c to continue without paging-- e<0> (this=<optimized out>) at /usr/include/c++/13/bits/std_thread.h:292 #12 std::thread::_Invoker<std::tuple<Scintilla::Internal::EditView::LayoutLine(const Scintilla::Internal::EditModel&, Scintilla::Internal::Surface*, const Scintilla::Internal::ViewStyle&, Scintilla::Internal::LineLayout*, int, bool)::<lambda()> > >::operator() (this=<optimized out>) at /usr/include/c++/13/bits/std_thread.h:299 #13 std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::thread::_Invoker<std::tuple<Scintilla::Internal::EditView::LayoutLine(const Scintilla::Internal::EditModel&, Scintilla::Internal::Surface*, const Scintilla::Internal::ViewStyle&, Scintilla::Internal::LineLayout*, int, bool)::<lambda()> > >, void>::operator() (this=<optimized out>) at /usr/include/c++/13/future:1432 #14 std::__invoke_impl<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::thread::_Invoker<std::tuple<Scintilla::Internal::EditView::LayoutLine(const Scintilla::Internal::EditModel&, Scintilla::Internal::Surface*, const Scintilla::Internal::ViewStyle&, Scintilla::Internal::LineLayout*, int, bool)::<lambda()> > >, void>&> (__f=<optimized out>) at /usr/include/c++/13/bits/invoke.h:61 #15 std::__invoke_r<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::thread::_Invoker<std::tuple<Scintilla::Internal::EditView::LayoutLine(const Scintilla::Internal::EditModel&, Scintilla::Internal::Surface*, const Scintilla::Internal::ViewStyle&, Scintilla::Internal::LineLayout*, int, bool)::<lambda()> > >, void>&> (__fn=<optimized out>) at /usr/include/c++/13/bits/invoke.h:116 #16 std::_Function_handler<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter>(), std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::thread::_Invoker<std::tuple<Scintilla::Internal::EditView::LayoutLine(const Scintilla::Internal::EditModel&, Scintilla::Internal::Surface*, const Scintilla::Internal::ViewStyle&, Scintilla::Internal::LineLayout*, int, bool)::<lambda()> > >, void> >::_M_invoke(const std::_Any_data &) (__functor=<error reading variable: Cannot access memory at address 0x7fffffffb568>) at /usr/include/c++/13/bits/std_function.h:291 --Type <RET> for more, q to quit, c to continue without paging--c #17 0x00007ffff7dbc592 in std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>::operator()() const (this=<optimized out>) at /usr/include/c++/13/bits/std_function.h:591 #18 std::__future_base::_State_baseV2::_M_do_set(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*) (this=0x5555587cdf50, __f=<optimized out>, __did_set=0x7fffffffb6a7) at /usr/include/c++/13/future:589 #19 0x00007ffff78a1ec3 in __pthread_once_slow (once_control=0x5555587cdf68, init_routine=0x7ffff68e93b0 <__once_proxy>) at ./nptl/pthread_once.c:116 #20 0x00007ffff7de8b0d in __gthread_once (__func=<optimized out>, __once=<error reading variable: Cannot access memory at address 0x7fffffffb678>) at /usr/include/x86_64-linux-gnu/c++/13/bits/gthr-default.h:700 #21 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) (__f=<error reading variable: Cannot access memory at address 0x7fffffffb6c0>, __once=<error reading variable: Cannot access memory at address 0x7fffffffb678>) at /usr/include/c++/13/mutex:907 #22 std::__future_base::_State_baseV2::_M_set_result(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>, bool) (__ignore_failure=true, __res=Python Exception <class 'gdb.MemoryError'>: Cannot access memory at address 0x7fffffffb6f0
#23 std::__future_base::_Deferred_state<std::thread::_Invoker<std::tuple<Scintilla::Internal::EditView::LayoutLine(const Scintilla::Internal::EditModel&, Scintilla::Internal::Surface*, const Scintilla::Internal::ViewStyle&, Scintilla::Internal::LineLayout*, int, bool)::<lambda()> > >, void>::_M_complete_async(void) (this=<error reading variable: Cannot access memory at address 0x7fffffffb678>) at /usr/include/c++/13/future:1705 #24 0x00007ffff7de6487 in std::__future_base::_State_baseV2::wait (this=0x5555587cdf50) at /usr/include/c++/13/future:347 #25 std::__basic_future<void>::wait (this=0x555555bf95d0) at /usr/include/c++/13/future:716 #26 Scintilla::Internal::EditView::LayoutLine (this=<optimized out>, model=<optimized out>, surface=<optimized out>, vstyle=<optimized out>, ll=<optimized out>, width=<optimized out>, callerMultiThreaded=<optimized out>) at ../scintilla/src/EditView.cxx:518
erm, thats not the whole backtrace, [expletive deleted] GDB pages it and needs you to keep pressing until you get it all.
Much of this stack, from 25 `std::__basic_future::wait` to 8 `operator()` is C++ standard library implementation details for running a a task potentially in multiple threads with `std::async`.
Key thing to find out is whether Geany has enabled multithreaded layout by calling `SCI_SETLAYOUTTHREADS`. The same code will run single threaded but uses the `deferred` policy which is equivalent to just calling the task.
A potential clue is the apparent size of the vector being processed by `LayoutSegments`: 1499999 so 1.5 million segments (lexemes like number or identifier) in a wide line of text although the piece of that text being measured by `MeasureWidthsUTF8` is just "728333".
Hmmm, @DavParc are you displaying/editing a minimised HTML or similar thing that is large, long lines or one line, with wrapping on? And does the "freeze" happen when the window is covered by another window or minimised for a period?
@nyamatongwe no Geany does not set SCI_SETLAYOUTTHREADS so IIUC that means one thread. I guess it could be set if its guaranteed that Pango and any other GTK stack is multi-thread safe (I couldn't find "thread" in any pango docs). Or at least the usual Geany approach, have an option :-)
erm, thats not the whole backtrace, [expletive deleted] GDB pages it and needs you to keep pressing until you get it all.
Oh sorry. I thought I had pressed 'c' to get the whole lot. I'll be more careful next time. Yes, in this case I had a lot of data (plain text) in the file (about 1.4 million integers in 1 line) . Wrapping was on. I'll continue with another file which is not so extreme.
Wrapping is a hard problem, there is no simple method of finding where to wrap lines on the screen, it can only be found by laying out each line and seeing by trial and error if it fills the screen width ... for each screen line at a time. So it takes a lot of work each time the wrapping has to be done, and if your file is only one line of source then up to the point that is shown on the screen has to be laid out to find where the visible wrapping lines start. There are various cunning caching methods to assist it, but if you do something like make a change at the start of the buffer then move to the end of the buffer the wrapping of the _whole_ buffer has to be found again, and that will be a delay.
And it may be slow, hence an apparent "freeze" while it happens. This is a known "issue" but not one that can be removed, although as @nyamatongwe pointed out, it may be possible to use some more of your CPU cores to divide and conquer the work. But Geany does not support that yet.
So for debugging purposes it might be better to make your file bigger to get that problem to show up quicker to see if it is the cause, maybe double or triple the file for testing purposes. But those freezes should only be temporary and the bigger file should make wrapping more obviously the cause, though possibly slow, but there should be no permanent freezes.
Since you have mentioned permanent freezes, that may be something different and is really a real problem if it exists. So the thing is to see if you can catch the permanent freeze in GDB after it has been permanent for a significant period on a relatively smaller file so the distinction between a slow wrapping freeze and a permanent freeze is more obvious.
Understood. I'll run geany always with gdb and keep an eye. Also, I'll turn wrapping off if I have long lines of data.
Sorry to interrupt but I have exactly the same problem. If I enter something cpu goes up to 25% (4 threads) and then drops back to 0%. I have removed active_profiles and turned off wordwrap with no change.
If you need any further information you will have to do some handholding I'm afraid. I don't know much about debugging. Sorry.
@AndyM48 you need to provide more information, what operating system, what version of Geany, how are you measuring CPU usage?
Artix (Arch) Linux 6.10.10-artix1-1 #1 SMP PREEMPT_DYNAMIC Fri, 13 Sep 2024 03:28:40 +0000 x86_64 GNU/Linux Geany - "Pryce" (built on or after 2023-10-23) Using GTK+ v3.24.43 and GLib v2.82.1 runtime libraries
CPU level shown rising to 25% and dropping back after approx. 2 seconds in xfce4-taskmanager.
Thanks for the quick reply
Sounds normal, if I scroll a 5000 line C file up and down I can have up to somewhat more than 120% for a few seconds. However that does not freeze Geany.
Apps like xfce4-taskmanager or system-monitor or other similar are sampling and averaging CPU which results in usage being smeared, and unless you can show only the Geany cpu usage it will include the graphics driver CPU and OS CPU.
No, this is not normal. It only happens in Geany, when I am editing an existing file and then not always. I will try and work out when and why it happens.
The file I have been working on is only 95,232 bytes, maximum line length approx.244 characters. I have closed all the tabs and it still shows cpu 25% when I enter text. The taskmanager shows the geany cpu usage:  Note that the 1.06% above rises to 25% and then drops back when the problem occurs.
Close all the plugins. How often is the task manager sampling? And confirm shows 25% each single character you type.
All the plugins are closed
Refresh rate of taskmanager is set to 750ms
Seems to happen after several (7?) characters are typed.
github-comments@lists.geany.org