The current code uses an unreffed TMSourceFile->short_name as the key into source_file_map. With Geany itself this is no problem as the TMSourceFiles are always destroyed after their removal from the hash table.

However, if a plugin adds 2 different files to the TM using

tm_workspace_add_source_file(file1);
tm_workspace_add_source_file(file2);

that have a different path but the same file name, such as

/A/B/myfile.c
/C/D/myfile.c

and at a later point removes them using something like

tm_workspace_remove_source_file(file1);
tm_source_file_free(file1);
tm_workspace_remove_source_file(file2);
tm_source_file_free(file2);

the

tm_source_file_free(file1);

call deallocates the key in the hash table which is now an invalid pointer and the subsequent

tm_workspace_remove_source_file(file2);

crashes the plugin.

While it would be possible to solve this crash at the plugin level by reordering the operations such as

tm_workspace_remove_source_file(file1);
tm_workspace_remove_source_file(file2);
tm_source_file_free(file1);
tm_source_file_free(file2);

this is not obvious from the plugin's perspective which doesn't know Geany's internals so better to solve it at Geany's level by using a g_strdupped value as the key.

This problem currently happens with the ProjectOrganizer plugin.

You can view, comment on, or merge this pull request online at:

  https://github.com/geany/geany/pull/3443

Commit Summary

• 8cfa927 Prevent possible crash when using tm_workspace API by plugins

File Changes

(1 file)

• M src/tagmanager/tm_workspace.c (4)

Patch Links:

• https://github.com/geany/geany/pull/3443.patch
• https://github.com/geany/geany/pull/3443.diff

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <geany/geany/pull/3443@github.com>