The symbols pane does not update on save when opening through gvfs-fuse. This used to work well in 0.15.
To reproduce:
1. Use nautilus to mount a remote ssh:// 2. Open a source file (I use c++). 3. type a comment or space and click save. 4. Notice symbol navigation no longer works. 5. Ctrl+R to reload seems to make it work until next save.
On Mon, 16 Feb 2009 10:35:25 +1100, "James ." jazzrz86@gmail.com wrote:
The symbols pane does not update on save when opening through gvfs-fuse. This used to work well in 0.15.
To reproduce:
- Use nautilus to mount a remote ssh://
- Open a source file (I use c++).
- type a comment or space and click save.
- Notice symbol navigation no longer works.
- Ctrl+R to reload seems to make it work until next save.
Works fine here at least when reproducing with the information you provided.
GVfs/GTK/GLib versions would be interesting as well as type and name of the remote connection. Maybe also the full path of the file you tried and its size.
Regards, Enrico
This patch seems to be an acceptable workaround for the problem. I noticed that if I use "save all", the symbols update normally. I am also getting a lot of spurious gtk errros about invalid casts to notebook, I will post up the errors when I have time, but I dont think that and this are related.
On Mon, Feb 16, 2009 at 11:19 PM, Enrico Tröger enrico.troeger@uvena.de wrote:
On Mon, 16 Feb 2009 10:35:25 +1100, "James ." jazzrz86@gmail.com wrote:
The symbols pane does not update on save when opening through gvfs-fuse. This used to work well in 0.15.
To reproduce:
- Use nautilus to mount a remote ssh://
- Open a source file (I use c++).
- type a comment or space and click save.
- Notice symbol navigation no longer works.
- Ctrl+R to reload seems to make it work until next save.
Works fine here at least when reproducing with the information you provided.
GVfs/GTK/GLib versions would be interesting as well as type and name of the remote connection. Maybe also the full path of the file you tried and its size.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Mon, 16 Feb 2009 23:35:19 +1100, "James ." jazzrz86@gmail.com wrote:
This patch seems to be an acceptable workaround for the problem. I
No. If you want to use that ok, but it's not a solution. I'd like to get to the problem before thinking about workarounds.
Especially, some more information would be great but you completely ignored my last request.
also getting a lot of spurious gtk errros about invalid casts to notebook, I will post up the errors when I have time, but I dont think that and this are related.
Yeah, had been reported earlier already but we still need to track these down. If you'll get any idea, please tell us. And yes, it's unlikely that the symbol ist update problem and the notebook warnings re related.
Regards, Enrico
My apologies. I did not mean to ignore your request for more information, I was no longer at work and therefore it would be difficult to provide accurate information.
Anyway, the system is using: GTK+ 2.14.7 / GLib 2.18.4 gvfs 1.0.3 Gnome 2.24.3 Linux 2.6.28.5 (i686) Slackware 12.2 base
The remote connection is a SSH, however the file is opened through gvfs-fuse by double clicking the remote file in nautilus. All the files I open exhibit this behaviour, and I dont believe theres anything special about these files. The full path is:
sftp://user@server/home/user/playpen/rostering/src/xml/XmlParser.cc
and its file size is 14.3KB.
On Mon, Feb 16, 2009 at 11:50 PM, Enrico Tröger enrico.troeger@uvena.de wrote:
On Mon, 16 Feb 2009 23:35:19 +1100, "James ." jazzrz86@gmail.com wrote:
This patch seems to be an acceptable workaround for the problem. I
No. If you want to use that ok, but it's not a solution. I'd like to get to the problem before thinking about workarounds.
Especially, some more information would be great but you completely ignored my last request.
also getting a lot of spurious gtk errros about invalid casts to notebook, I will post up the errors when I have time, but I dont think that and this are related.
Yeah, had been reported earlier already but we still need to track these down. If you'll get any idea, please tell us. And yes, it's unlikely that the symbol ist update problem and the notebook warnings re related.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
I also found another bug with the symbols sidebar. Sometimes the tooltips are empty. As it turns out, the hacked up workaround doesnt actually work, it makes it work only for the current tab, and as soon as you save any document through this remote connection the symbols sidebar loses its tracking and clicking will not take you to the correct function. A better workaround is to right click the sidebar and reclick "sort by name", which will make the clicking to a function work again.
I will also upload the cpp file which causes the tooltip bug.
On Tue, Feb 17, 2009 at 10:03 AM, James . jazzrz86@gmail.com wrote:
My apologies. I did not mean to ignore your request for more information, I was no longer at work and therefore it would be difficult to provide accurate information.
Anyway, the system is using: GTK+ 2.14.7 / GLib 2.18.4 gvfs 1.0.3 Gnome 2.24.3 Linux 2.6.28.5 (i686) Slackware 12.2 base
The remote connection is a SSH, however the file is opened through gvfs-fuse by double clicking the remote file in nautilus. All the files I open exhibit this behaviour, and I dont believe theres anything special about these files. The full path is:
sftp://user@server/home/user/playpen/rostering/src/xml/XmlParser.cc
and its file size is 14.3KB.
On Mon, Feb 16, 2009 at 11:50 PM, Enrico Tröger enrico.troeger@uvena.de wrote:
On Mon, 16 Feb 2009 23:35:19 +1100, "James ." jazzrz86@gmail.com wrote:
This patch seems to be an acceptable workaround for the problem. I
No. If you want to use that ok, but it's not a solution. I'd like to get to the problem before thinking about workarounds.
Especially, some more information would be great but you completely ignored my last request.
also getting a lot of spurious gtk errros about invalid casts to notebook, I will post up the errors when I have time, but I dont think that and this are related.
Yeah, had been reported earlier already but we still need to track these down. If you'll get any idea, please tell us. And yes, it's unlikely that the symbol ist update problem and the notebook warnings re related.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Wed, 18 Feb 2009 10:34:08 +1100, "James ." jazzrz86@gmail.com wrote:
Hi,
I also found another bug with the symbols sidebar. Sometimes the tooltips are empty. As it turns out, the hacked up workaround doesnt
Thanks, your testfile helped a lot. The empty tooltip bug is fixed in SVN. It basically was caused by the ampersands in the function signatures which screwed up GTK's tooltip code (it expects markup but we passed it as plain text).
actually work, it makes it work only for the current tab, and as soon as you save any document through this remote connection the symbols sidebar loses its tracking and clicking will not take you to the correct function. A better workaround is to right click the sidebar
Sigh, I have basically the same setup as you (GTK 2.14.7, GLib 2.18.4, GVfs 1.0.3) but it all works fine. The symbol list gets updated here, when adding/removing lines the line numbers in the symbol names in the list are updated and clicking them jumps me to the correct line.
Even though unlikely (I'm just guessing around): working with the same file locally works as expected? I.e. does the same weird things happen with the file you used remotely when you save it locally and edit it? I just don't see what is special to remote files since they are accessed through gvfs-fuse as local files.
Regards, Enrico
Yes, I dont know why this happens only over the ssh connection at my work. I tried several different connections, including ssh and ftp, and they all seem to work fine. It is almost as if its a gvfs issue except that geany worked fine in 0.15.
One thing i did notice about the bug is that as soon as the document gets saved, the line numbers and the tree structure is correct, BUT clicking on the function in the symbols tree no longer points to the correct line in the editor, and sometimes it will not respond to clicks at all. As mentioned earlier, just resorting the tree returns the functionality(temporarily). So the question is, when are the "click" callbacks on the tree allocated to each item? Are they linked to the sci editor in anyway? and are the line numbers kept in memory along with the document or are they read again through a file operation that would cause some error and not be read in? Some idea to parts of the code that does these things would help, maybe I can find the problem.
Thanks.
On Thu, Feb 19, 2009 at 2:34 AM, Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 18 Feb 2009 10:34:08 +1100, "James ." jazzrz86@gmail.com wrote:
Hi,
I also found another bug with the symbols sidebar. Sometimes the tooltips are empty. As it turns out, the hacked up workaround doesnt
Thanks, your testfile helped a lot. The empty tooltip bug is fixed in SVN. It basically was caused by the ampersands in the function signatures which screwed up GTK's tooltip code (it expects markup but we passed it as plain text).
actually work, it makes it work only for the current tab, and as soon as you save any document through this remote connection the symbols sidebar loses its tracking and clicking will not take you to the correct function. A better workaround is to right click the sidebar
Sigh, I have basically the same setup as you (GTK 2.14.7, GLib 2.18.4, GVfs 1.0.3) but it all works fine. The symbol list gets updated here, when adding/removing lines the line numbers in the symbol names in the list are updated and clicking them jumps me to the correct line.
Even though unlikely (I'm just guessing around): working with the same file locally works as expected? I.e. does the same weird things happen with the file you used remotely when you save it locally and edit it? I just don't see what is special to remote files since they are accessed through gvfs-fuse as local files.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Thu, 19 Feb 2009 12:27:15 +1100, "James ." jazzrz86@gmail.com wrote:
Yes, I dont know why this happens only over the ssh connection at my work. I tried several different connections, including ssh and ftp, and they all seem to work fine. It is almost as if its a gvfs issue except that geany worked fine in 0.15.
One thing i did notice about the bug is that as soon as the document gets saved, the line numbers and the tree structure is correct, BUT
Ok, this is fine.
clicking on the function in the symbols tree no longer points to the correct line in the editor, and sometimes it will not respond to clicks at all. As mentioned earlier, just resorting the tree returns
Now it becomes interesting :).
the functionality(temporarily). So the question is, when are the "click" callbacks on the tree allocated to each item? Are they linked to the sci editor in anyway? and are the line numbers kept in memory
No, they are not linked to the editor. The tree items have attached a reference to a TMTag structure which contains beside other information the line number of the symbol in the file. When clicking on a tree item in list, the TMTag structure is read to obtain the associated line number. Then we go to to this line in the current document.
You said sometimes it jumps to the wrong line number or doesn't jump at all. This is probably caused by the same problem: I guess the line number which is read from the attached TMTag struct is wrong or the TMTag struct reference itself is wrong. So, when you click an item and nothing happens, it just means the read line number is out of range (less than 0 or greater than the max line count in the document).
If you have a little time, please apply the attached patch to your sources and recheck the whole thing. The patch attaches a the line number directly to the symbol list items and use it when one is clicked. This might change something or might not. Additionally it adds some warning messages if the line numbers doesn't match or the treeview widget doesn't match with the one of the current document. I'm not sure if any of these warnings are triggered at all but maybe it helps to track down the problem. (to check for the warnings see Help->Debug Messages)
But after all, I think what you described is more or less only a symptom of the real problem, not the problem itself. Especially because you say it happens only on one ssh connection and not on others and that re-ordering the symbol list fixes it. Maybe there is a problem when saving the file, maybe the tagmanager doesn't rescan the file correctly or there is some kind of race condition when saving. But first, the changes with the patch would be interesting.
Regards, Enrico
Thanks for the patch. After some short time of debugging, I finally found the root cause of the problem. It is indeed a race condition, and the reason geany 0.15 did not catch this is because it duplicated all the tags in get_tag_list whereas now, all the tags come straight from the tag manager.
As it turns out, the tag manager makes some naive assumptions about when the file is updated and the time it analyze the tags:
from tm_work_object.c:
time_t tm_get_file_timestamp(const char *file_name) { struct stat s;
g_return_val_if_fail(file_name, 0);
if (0 != g_stat(file_name, &s)) { /*g_warning("Unable to stat %s", file_name);*/ return (time_t) 0; } else return s.st_mtime; }
gboolean tm_work_object_is_changed(TMWorkObject *work_object) { return (gboolean) (work_object->analyze_time < tm_get_file_timestamp(work_object->file_name)); }
from tm_source_file.c:
gboolean tm_source_file_update(TMWorkObject *source_file, gboolean force , gboolean __unused__ recurse, gboolean update_parent) { if (force || (tm_work_object_is_changed(source_file))) { tm_source_file_parse(TM_SOURCE_FILE(source_file)); tm_tags_sort(source_file->tags_array, NULL, FALSE); source_file->analyze_time = time(NULL); if ((source_file->parent) && update_parent) { tm_work_object_update(source_file->parent, TRUE, FALSE, TRUE); } return TRUE; } else { #ifdef TM_DEBUG g_message ("no parsing of %s has been done", source_file->file_name); #endif return FALSE; } }
as you can see, while tm_work_object_is_changed compares analyze_time with the file timestamp, the update function only feeds the CURRENT time into analyze_time after its updated, which opens the door for some nasty race conditions when dealing with remote files.
The solution, thus is simply to update analyze_time with the file timestamp:
-source_file->analyze_time = time(NULL); +source_file->analyze_time = tm_get_file_timestamp(source_file->file_name);
and bingo, problem disappear for good, no hacks.
2009/2/20 Enrico Tröger enrico.troeger@uvena.de:
On Thu, 19 Feb 2009 12:27:15 +1100, "James ." jazzrz86@gmail.com wrote:
Yes, I dont know why this happens only over the ssh connection at my work. I tried several different connections, including ssh and ftp, and they all seem to work fine. It is almost as if its a gvfs issue except that geany worked fine in 0.15.
One thing i did notice about the bug is that as soon as the document gets saved, the line numbers and the tree structure is correct, BUT
Ok, this is fine.
clicking on the function in the symbols tree no longer points to the correct line in the editor, and sometimes it will not respond to clicks at all. As mentioned earlier, just resorting the tree returns
Now it becomes interesting :).
the functionality(temporarily). So the question is, when are the "click" callbacks on the tree allocated to each item? Are they linked to the sci editor in anyway? and are the line numbers kept in memory
No, they are not linked to the editor. The tree items have attached a reference to a TMTag structure which contains beside other information the line number of the symbol in the file. When clicking on a tree item in list, the TMTag structure is read to obtain the associated line number. Then we go to to this line in the current document.
You said sometimes it jumps to the wrong line number or doesn't jump at all. This is probably caused by the same problem: I guess the line number which is read from the attached TMTag struct is wrong or the TMTag struct reference itself is wrong. So, when you click an item and nothing happens, it just means the read line number is out of range (less than 0 or greater than the max line count in the document).
If you have a little time, please apply the attached patch to your sources and recheck the whole thing. The patch attaches a the line number directly to the symbol list items and use it when one is clicked. This might change something or might not. Additionally it adds some warning messages if the line numbers doesn't match or the treeview widget doesn't match with the one of the current document. I'm not sure if any of these warnings are triggered at all but maybe it helps to track down the problem. (to check for the warnings see Help->Debug Messages)
But after all, I think what you described is more or less only a symptom of the real problem, not the problem itself. Especially because you say it happens only on one ssh connection and not on others and that re-ordering the symbol list fixes it. Maybe there is a problem when saving the file, maybe the tagmanager doesn't rescan the file correctly or there is some kind of race condition when saving. But first, the changes with the patch would be interesting.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Fri, 20 Feb 2009 14:45:04 +1100, "James ." jazzrz86@gmail.com wrote:
Thanks for the patch. After some short time of debugging, I finally found the root cause of the problem. It is indeed a race condition, and the reason geany 0.15 did not catch this is because it duplicated all the tags in get_tag_list whereas now, all the tags come straight from the tag manager.
As it turns out, the tag manager makes some naive assumptions about when the file is updated and the time it analyze the tags:
from tm_work_object.c:
[snipped code]
as you can see, while tm_work_object_is_changed compares analyze_time with the file timestamp, the update function only feeds the CURRENT time into analyze_time after its updated, which opens the door for some nasty race conditions when dealing with remote files.
The solution, thus is simply to update analyze_time with the file timestamp:
-source_file->analyze_time = time(NULL); +source_file->analyze_time = tm_get_file_timestamp (source_file->file_name);
and bingo, problem disappear for good, no hacks.
Wow, many thanks for getting so deeply into the problem and actually finding the evil thing.
Yesterday, I had the tagmanager file changed code shortly in mind but then when writing the mail, I already forgot about it. But great it's now up again. I was wondering this already for a long time: I think we can completely drop the tm_work_object_is_changed() call in tm_source_file_update() because when we call tm_source_file_update() in Geany, we really want to reload the tags, e.g. at re-reading the symbol list after a file has saved. So, there is basically no need to keep the file time checks in tagmanager and by removing it we would also save a stat() call on the file which would be great especially for remote files.
I will have a deeper look into this next week and either commit your fix to use the correct time value or drop the whole code as mentioned above.
Thanks again.
Regards, Enrico