[Geany] Regression in 0.16 with symbols and gvfs remote files.

[James .]

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 at uvena.de>:
> On Thu, 19 Feb 2009 12:27:15 +1100, "James ." <jazzrz86 at 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 at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
>
>