Closing some directory structure from the sidebar tree (when showing the tree at least) sometimes crashes on master (and always makes Valgrind angry).
Steps to reproduce:
Given this file tree:
```shell
$ find /tmp/root/ -type f
/tmp/root/2
/tmp/root/1/1.1/1.1.2
/tmp/root/1/1.1/1.1.1
/tmp/root/1/1.2/1.2.2
/tmp/root/1/1.2/1.2.1
```
1. run Geany on those files (`geany -c /tmp/_new_config $(find /tmp/root/ -type f)`
2. right-click on e.g. directory `/tmp/root/1` in the document sidebar, and select "close"
3. you'll either see a crash, or that not everything under that directory got closed properly
Here's Valgrind being unhappy:
```console
$ valgrind geany -c /tmp/_new_config $(find /tmp/root/ -type f)
[…]
==917061== Invalid read of size 8
==917061== at 0x5B31345: g_node_nth_child (gnode.c:1052)
==917061== by 0x50A7361: gtk_tree_store_iter_nth_child (gtktreestore.c:793)
==917061== by 0x491DB76: on_openfiles_document_action_apply (sidebar.c:1330)
==917061== by 0x491DC0C: on_openfiles_document_action (sidebar.c:1347)
==917061== by 0x5A833AF: g_closure_invoke (gclosure.c:832)
==917061== by 0x5A96075: signal_emit_unlocked_R.isra.0 (gsignal.c:3796)
==917061== by 0x5A9CBF4: g_signal_emit_valist (gsignal.c:3549)
==917061== by 0x5A9CDBE: g_signal_emit (gsignal.c:3606)
==917061== by 0x50D7833: gtk_widget_activate (gtkwidget.c:7845)
==917061== by 0x4F8A935: gtk_menu_shell_activate_item (gtkmenushell.c:1375)
==917061== by 0x4F8AC70: gtk_menu_shell_button_release (gtkmenushell.c:791)
==917061== by 0x4DFBCB3: _gtk_marshal_BOOLEAN__BOXEDv (gtkmarshalers.c:130)
==917061== Address 0x9bcdc20 is 32 bytes inside a block of size 40 free'd
==917061== at 0x484317B: free (vg_replace_malloc.c:872)
==917061== by 0x5B3068B: g_nodes_free (gnode.c:123)
==917061== by 0x5B3068B: g_node_destroy (gnode.c:143)
==917061== by 0x50AA8F2: gtk_tree_store_remove (gtktreestore.c:1229)
==917061== by 0x491F851: sidebar_openfiles_remove_iter (sidebar.c:959)
==917061== by 0x491F8AE: openfiles_remove (sidebar.c:972)
==917061== by 0x491FA6C: sidebar_remove_document (sidebar.c:1027)
==917061== by 0x48D0B5B: remove_page (document.c:733)
==917061== by 0x48D29C0: document_remove_page (document.c:787)
==917061== by 0x48D29FC: document_close (document.c:695)
==917061== by 0x491DAED: document_action (sidebar.c:1299)
==917061== by 0x491DB47: on_openfiles_document_action_apply (sidebar.c:1322)
==917061== by 0x491DB9E: on_openfiles_document_action_apply (sidebar.c:1332)
==917061== Block was alloc'd at
==917061== at 0x48407B4: malloc (vg_replace_malloc.c:381)
==917061== by 0x5B2C678: g_malloc (gmem.c:130)
==917061== by 0x5B45011: g_slice_alloc (gslice.c:1074)
==917061== by 0x5B305BD: g_node_new (gnode.c:110)
==917061== by 0x50AAF0B: gtk_tree_store_insert_before (gtktreestore.c:1375)
==917061== by 0x491E725: tree_add_new_dir (sidebar.c:654)
==917061== by 0x491E89A: get_parent_for_file (sidebar.c:840)
==917061== by 0x491E995: sidebar_openfiles_add_iter (sidebar.c:869)
==917061== by 0x491F5C7: sidebar_openfiles_add (sidebar.c:901)
==917061== by 0x48D0CE4: document_create (document.c:662)
==917061== by 0x48D3840: document_open_file_full (document.c:1349)
==917061== by 0x48D3C81: document_open_file (document.c:914)
==917061==
```
I believe this is due to collapsing directories together when there's only one child. This leads to tree iters changing, and overall structure shifting while navigating it -- even if it's down from the bottom-up depth-first as it is.
It's probably not trivial to fix, and I failed to do so quickly. One reason why it's not that easy is that it has to handle all this shifting *and* allow the tree to stay in the end if e.g. a file was not saved and the user cancelled the close request (my attempt was just to repeatedly close the first node until there was no more, but obviously that's not working).
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3527
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3527(a)github.com>
When the openfiles sidebar shows documents as a tree, closing a document can lead to sever re-layout of the view (e.g. collapsing directory nodes together). This makes walking the tree and closing documents at the same time highly tricky, as nodes might be shifting as we go.
This lead to invalid memory access, and unexpected results, when closing some tree structures.
One example of Valgrind showing how bad things are:
==917061== Invalid read of size 8
==917061== at 0x5B31345: g_node_nth_child (gnode.c:1052)
==917061== by 0x50A7361: gtk_tree_store_iter_nth_child (gtktreestore.c:793)
==917061== by 0x491DB76: on_openfiles_document_action_apply (sidebar.c:1330)
==917061== by 0x491DC0C: on_openfiles_document_action (sidebar.c:1347)
==917061== by 0x5A833AF: g_closure_invoke (gclosure.c:832)
==917061== by 0x5A96075: signal_emit_unlocked_R.isra.0 (gsignal.c:3796)
==917061== by 0x5A9CBF4: g_signal_emit_valist (gsignal.c:3549)
==917061== by 0x5A9CDBE: g_signal_emit (gsignal.c:3606)
==917061== by 0x50D7833: gtk_widget_activate (gtkwidget.c:7845)
==917061== by 0x4F8A935: gtk_menu_shell_activate_item (gtkmenushell.c:1375)
==917061== by 0x4F8AC70: gtk_menu_shell_button_release (gtkmenushell.c:791)
==917061== by 0x4DFBCB3: _gtk_marshal_BOOLEAN__BOXEDv (gtkmarshalers.c:130)
==917061== Address 0x9bcdc20 is 32 bytes inside a block of size 40 free'd
==917061== at 0x484317B: free (vg_replace_malloc.c:872)
==917061== by 0x5B3068B: g_nodes_free (gnode.c:123)
==917061== by 0x5B3068B: g_node_destroy (gnode.c:143)
==917061== by 0x50AA8F2: gtk_tree_store_remove (gtktreestore.c:1229)
==917061== by 0x491F851: sidebar_openfiles_remove_iter (sidebar.c:959)
==917061== by 0x491F8AE: openfiles_remove (sidebar.c:972)
==917061== by 0x491FA6C: sidebar_remove_document (sidebar.c:1027)
==917061== by 0x48D0B5B: remove_page (document.c:733)
==917061== by 0x48D29C0: document_remove_page (document.c:787)
==917061== by 0x48D29FC: document_close (document.c:695)
==917061== by 0x491DAED: document_action (sidebar.c:1299)
==917061== by 0x491DB47: on_openfiles_document_action_apply (sidebar.c:1322)
==917061== by 0x491DB9E: on_openfiles_document_action_apply (sidebar.c:1332)
==917061== Block was alloc'd at
==917061== at 0x48407B4: malloc (vg_replace_malloc.c:381)
==917061== by 0x5B2C678: g_malloc (gmem.c:130)
==917061== by 0x5B45011: g_slice_alloc (gslice.c:1074)
==917061== by 0x5B305BD: g_node_new (gnode.c:110)
==917061== by 0x50AAF0B: gtk_tree_store_insert_before (gtktreestore.c:1375)
==917061== by 0x491E725: tree_add_new_dir (sidebar.c:654)
==917061== by 0x491E89A: get_parent_for_file (sidebar.c:840)
==917061== by 0x491E995: sidebar_openfiles_add_iter (sidebar.c:869)
==917061== by 0x491F5C7: sidebar_openfiles_add (sidebar.c:901)
==917061== by 0x48D0CE4: document_create (document.c:662)
==917061== by 0x48D3840: document_open_file_full (document.c:1349)
==917061== by 0x48D3C81: document_open_file (document.c:914)
Fix this by decoupling tree walking from closing documents. We now do two passes: first we collect documents to work on walking the tree as before, and only then we perform the action on each node of the list.
Fixes #3527.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3535
-- Commit Summary --
* Fix crash closing directory from the openfiles sidebar
-- File Changes --
M src/sidebar.c (29)
-- Patch Links --
https://github.com/geany/geany/pull/3535.patchhttps://github.com/geany/geany/pull/3535.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3535
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3535(a)github.com>
After some more thinking about it, we can fix #3454 very easily by ourselves by checking whether the tag originates from a source file with a known/common C/C++ extension - if not, always set "local" to FALSE.
The first patch adds `is_c_source` flag to TMSourceFile to indicate whether the file has one of the known C/C++ extensions, the second patch uses this flag and for C/C++ sources sets "local" to TRUE only when this flag is set (in addition to ctag's isFileScope flag).
@b4n Does this fix look OK to you?
Fixes #3454.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3490
-- Commit Summary --
* Add a flag to TMSourceFile indicating whether it's a C/C++ source file
* For C/C++ only mark tag as local if it originates from a source file
-- File Changes --
M src/tagmanager/tm_ctags.c (7)
M src/tagmanager/tm_source_file.c (18)
M src/tagmanager/tm_source_file.h (2)
-- Patch Links --
https://github.com/geany/geany/pull/3490.patchhttps://github.com/geany/geany/pull/3490.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3490
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3490(a)github.com>
Having 2 files, *xx.foo* and *something.c* open as C (assume the *.foo* was a header or something):
<details><summary><em>xx.foo</em></summary>
```c
int xx_foo(int n);
```
</details>
<details><summary><em>something.c</em></summary>
```c
int main(void)
{
xx_foo(); // (1)
}
```
</details>
At `(1)`, neither autocompletion nor "go to tag" works, but calltip does.
Quick code look suggests that the `TMTag->lang` probably is wrong (I guess using the ctags-detected language (none?) instead of the actual parer's language?).
Causes real issues with a codebase full of `.hdl`s loaded as C++ (which are auto-generated headers included in just as auto-generated `.hxx`es).
@techee if you have insight that'd be amazing, otherwise I'll try and look at this deeper when (read: if :grin:) I get time.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3454
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3454(a)github.com>
Depends on #2355 for docs.
* Add *Project patterns* to open dialog file filters
* Re-use "File patterns" string in Find in Files dialog vs "Files" for clarity
* Show ungrouped filetypes first in open dialog file filter (fixes #2296 - see [this comment in particular](https://github.com/geany/geany/issues/2296#issuecomment-5337963…)
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/2356
-- Commit Summary --
* Add *Project patterns* to open dialog file filters
* Show ungrouped filetypes first in open dialog file filter
* docs: Document Open dialog options
* Update filter docs
* Re-use "File patterns" string in Find in Files dialog vs "Files"
-- File Changes --
M data/geany.glade (2)
M doc/geany.txt (40)
M src/dialogs.c (29)
M src/search.c (2)
-- Patch Links --
https://github.com/geany/geany/pull/2356.patchhttps://github.com/geany/geany/pull/2356.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/2356
When using *Tools->Config Files* to open a user file that doesn't exist.
This fixes the first line of `geany.css` being wrongly uncommented (and the rest unchanged) due to toggle comment being used and CSS not having a line comment.
Split out from #3396 as it's independent of it.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3450
-- Commit Summary --
* Don't comment global content unless it is Conf
-- File Changes --
M src/ui_utils.c (3)
-- Patch Links --
https://github.com/geany/geany/pull/3450.patchhttps://github.com/geany/geany/pull/3450.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3450
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3450(a)github.com>
When using Tools->Config Files to open a user file that doesn't exist. This fixes the first line of geany.css being wrongly uncommented (and the rest unchanged) due to toggle comment being used and CSS not having a line comment.
(Verbatim copy-paste of Nick's description of the previous version of the patch, thanks :-)
This is a replacement of https://github.com/geany/geany/pull/3450 which was done against an older version of Geany and the affected code was modified in the meantime.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3576
-- Commit Summary --
* Don't comment global content unless it is Conf
-- File Changes --
M src/ui_utils.c (6)
-- Patch Links --
https://github.com/geany/geany/pull/3576.patchhttps://github.com/geany/geany/pull/3576.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3576
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3576(a)github.com>