If I click on the help button in the Plugin Manager then it shows me the help for that plugin. This usually works fine.
But if I enable and disable a plugin a few times and click on help after that, then geany will crash quite likely. This happens no matter if the plugin is using the old or new plugin API. Also the kind of help shown does not seem to make a difference, e.g.: - the Latex plugin opens a info dialog - other plugins open a webpage
In both cases I could re-produce the crash. I tested with a quite actual development version of geany under Ubuntu 16.04, GTK3 build.
I cannot reproduce here. Could [post a backtrace](https://www.geany.org/Support/Bugs) to see where it's crashing?
Did you try enabling/disabling a plugin fast? (On-Off-On-Off-On-Off-On-Help ==> crash)
Cannot re-produce it myself now. I am now on GTK2. Will try some time later again with GTK3.
I did try that with several different plugins.
Ok, I can only reproduce it with a GTK3 based build. Here is the backtrace: ``` (gdb) bt #0 0x0000000000000000 in ?? () #1 0x00007ffff799dc4e in pm_on_plugin_button_clicked (button=<optimized out>, user_data=0x6) at plugins.c:1868 #2 0x00007ffff55b1fa5 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #3 0x00007ffff55c3fc1 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #4 0x00007ffff55ccd5c in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #5 0x00007ffff55cd08f in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #6 0x00007ffff55b21d4 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #7 0x00007ffff55cc9a6 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #8 0x00007ffff55cd08f in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #9 0x00007ffff6b2c6ad in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #10 0x00007ffff6b2c715 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #11 0x00007ffff55b1fa5 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #12 0x00007ffff55c3afc in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #13 0x00007ffff55ccd5c in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #14 0x00007ffff55cd08f in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #15 0x00007ffff6b2a7a0 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #16 0x00007ffff01cbe40 in ffi_call_unix64 () from /usr/lib/x86_64-linux-gnu/libffi.so.6 #17 0x00007ffff01cb8ab in ffi_call () from /usr/lib/x86_64-linux-gnu/libffi.so.6 #18 0x00007ffff55b2cf5 in g_cclosure_marshal_generic_va () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #19 0x00007ffff55b21d4 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #20 0x00007ffff55cc9a6 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #21 0x00007ffff55cd08f in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #22 0x00007ffff6bd8891 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #23 0x00007ffff55b4dbe in g_cclosure_marshal_VOID__BOXEDv () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #24 0x00007ffff55b21d4 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #25 0x00007ffff55cc9a6 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #26 0x00007ffff55cd08f in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #27 0x00007ffff6bd5bee in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #28 0x00007ffff6bd722b in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #29 0x00007ffff6bd9de5 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #30 0x00007ffff6ba9beb in gtk_event_controller_handle_event () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #31 0x00007ffff6d5abfb in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #32 0x00007ffff6c1f09a in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #33 0x00007ffff55b21d4 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #34 0x00007ffff55cc4b8 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #35 0x00007ffff55cd08f in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #36 0x00007ffff6d5cc3c in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #37 0x00007ffff6c1c3be in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #38 0x00007ffff6c1e1bc in gtk_main_do_event () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #39 0x00007ffff678bd92 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 #40 0x00007ffff50d7197 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #41 0x00007ffff50d73f0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #42 0x00007ffff50d7712 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #43 0x00007ffff6c1d395 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #44 0x00007ffff7999246 in main_lib (argc=1, argv=0x7fffffffdd08) at libmain.c:1250 #45 0x00007ffff735b830 in __libc_start_main (main=0x4005d0 <main>, argc=1, argv=0x7fffffffdd08, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdcf8) at ../csu/libc-start.c:291 #46 0x0000000000400609 in _start () ```
I did try that with several different plugins, built against GTK+ 3.22/GLib 2.54.1.
I read in another thread that GTK 3.22 is the only stable version. I am on Ubuntu 16.04, Geany running on GTK 3.18.9, GLib 2.48.2. So maybe it is not a geany issue but I cannot judge that.
Cannot reproduce, @LarsGit223 which plugin?
The line in the [BT](https://github.com/geany/geany/blob/7d2e6182110a24b505c732f221dd79415f174024...) indicates that cbs.help is null, and thats set [here](https://github.com/geany/geany/blob/7d2e6182110a24b505c732f221dd79415f174024...) which as you can see will set NULL in some circumstances, maybe fast activation/deactivation gets it out of sync. Activation may include loading the .so and therefore may be a slow process (relatively speaking) so your fast click might intercept a previous action. Just check that the plugin is actually enabled, even though the help is enabled, maybe its getting out of sync.
The plugin doesn't matter. I can re-produce it with every plugin that supports the help button/which has got an help button. To be explicit I re-produced it with this plugins: - Auto-Close - Auto-Mark - Code Navigation - Commander - Define formatter - GeanyCtags - Latex - Macros - Project Organizer - Spell Check - Workbench
I think it is not plugin related. The Number bookmarks crashed by just enabling/disabling it but that is definitely another plugin specific issue.
I will re-test now and see if waiting some seconds after the on-off phase makes a difference.
To point one thing out: it does not happen always but in far more than 50% of my attempts.
I tried waiting after the multiple On-Off-On-Switching. So I waited 5, 10 and 20seconds before clicking on "Help" but it did not make a difference. Still crashes. So as you say if something is "out of sync" it seems to stay "out of sync", waiting for something to finish does not seem to help (and my machine did not seem to be busy with anything during the waiting time. This is just my impression from "listening" - I did not check any system monitors).
Are you using the same GTK/glib versions?
I just downloaded the current master version of geany into a new, fresh directory and built that. No difference, sill crashes (just to be sure I did not mess something up in my other folder).
Are you using the same GTK/glib versions?
No GTK 3.18.9, GLib 2.48.2
I think its far more likely to be sensitive to the time between on and off, on is the thing that loads the .so and links symbols, ok, its likely to be faster the second and subsequent times, but still its some work. And if your version of Glib tries to do the module load asynchronously the UI may be active before everything is set up.
No GTK 3.18.9, GLib 2.48.2
I think you mis-read something. This are exactly the versions I use.
Oh, I read @codebrainz versions, oops :)
Never mind.
I can confirm it is the click speed between the On-Off which matters: - clicking in a one second speed (like _"21 - click - 22 -click - 23 - click"_) "solves" the problem, no crash - if I click fast then a single "On-Off-On-Help" or "Off-On-Help" sequence is enough to get the crash
I am currently on a different machine and only have Geany core plugins (all of which have no help) so I can't try it again, but one thing I noticed is that if you double click on the checkbox the selected row jumps to the top. Maybe you are double clicking and changing the selected row and confusing the PM.
I can confirm that.
The click speed in the bad case is that fast that the first row of the table gets selected shortly.
In the good case without the crash, the selected row does not change.
So somewhere maybe the PM is reading the active row instead of remembering which plugin its enabling, so its suddenly getting a disconnect between a plugin it thought had help and one that doesn't.
Hmmm...will try to give the first plugin a help. If your assumption is true it should then open the wrong help instead of crashing. But I will be gone now, maybe I got time for it in the evening. Thanks for your help.
@elextr: Good catch! :clap:
The first plugin in my list is Addons. If I give it a help function then in the good case I get the desired help (e.g. auto-mark). But in the bad case it opens the wrong help now (Addons) instead of crashing.
Closed #1781 via #1799.
github-comments@lists.geany.org