Verified that this happens on other notes as well.  Tried another note with
different content (but including the word "restart" in another context) with the
same effect.

I seem to have the same problem, so I'm not opening a new bug.

Version: 0.3.3-2ubuntu1~breezy1

The crash occoured wenn entering "opportuni": as soon as I tiped the "i" Tomboy crashed. I had a link to "Uni" in my "Start Here" note. Changing the Name of that link to something other (Universität) solved the problem for me.
Tiping "oportuni" didn't cause the crash.

Starting Tomboy from terminal with "mono --debug" I got the following backtrace:


Unhandled Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object
in <0x000a5> Tomboy.NoteLinkWatcher+Highlighter:TitleFound (System.String haystack, Int32 start_idx, System.Object value)
in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_string_int_object (string,int,object)
in <0x000e2> Tomboy.TrieTree:FindMatches (System.String haystack, Tomboy.MatchHandler match_handler)
in <0x000ba> Tomboy.NoteLinkWatcher+Highlighter:HighlightTrie (Tomboy.Note note, TextIter start, TextIter end, Tomboy.TrieTree trie)
in <0x000a3> Tomboy.NoteLinkWatcher:HighlightInBlock (TextIter start, TextIter end)
in <0x0010b> Tomboy.NoteLinkWatcher:OnInsertText (System.Object sender, Gtk.InsertTextArgs args)
in <0x00000> <unknown method>
in (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[])
in <0x0006f> System.Reflection.MonoMethod:Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture)--- End of inner exception stack trace ---

in <0x00104> System.Reflection.MonoMethod:Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture)
in <0x00017> System.Reflection.MethodBase:Invoke (System.Object obj, System.Object[] parameters)
in <0x000b3> System.Delegate:DynamicInvokeImpl (System.Object[] args)
in <0x00028> System.MulticastDelegate:DynamicInvokeImpl (System.Object[] args)
in <0x0000e> System.Delegate:DynamicInvoke (System.Object[] args)
in <0x001af> GtkSharp.voidObjectTextIterstringintSignal:voidObjectTextIterstringintCallback (IntPtr arg0, Gtk.TextIter arg1, System.String arg2, Int32 arg3, Int32 key)
in (wrapper native-to-managed) GtkSharp.voidObjectTextIterstringintSignal:voidObjectTextIterstringintCallback (intptr,Gtk.TextIter&,intptr,int,int)
in <0x00000> <unknown method>
in (wrapper managed-to-native) Gtk.Application:gtk_main ()
in <0x00007> Gtk.Application:Run ()
in <0x00007> Gnome.Program:Run ()
in <0x00036> Tomboy.Tomboy:StartTrayIcon ()
in <0x000d8> Tomboy.Tomboy:Main (System.String[] args)

With the latest CVS version from today, under the same conditions, "Uni" on "Start Here" and writing "opportuni", it no longer crashes, but creates a Note called "opportuni" stating there were a matching note named that way.

Matching Note title 'opportuni' at 493-502...

But there was no note called that way before I wrote "opportuni"...

So the crash ist solved in CVS, but it still does weird things :)

Changing the severity of this bug from critical to normal since crashing does not occur anymore.  Perhaps we should close this bug and open a new one to describe the other weird things that are going on.

I just did the following and got weird behavior:

1. Create a note titled "Uni"
2. Create another note "Other Note"
3. In "Other Note", type "auni buni cuni duni euni funi guni ... zuni"

"auni" and "buni" will be marked as active links to other notes.  When clicked on, they do not open the "Uni" note, but new notes titled "auni" and "buni" are created.  "cuni", "duni", etc. are not marked as links.

Created attachment 81797 [details]
Screenshot of the strange linking behavior

I'm using 0.7.3 and I can't reproduce any of the problems said on this bug. I think this bug should closed.

The strange linking behavior still exists, but the crashing doesn't occur anymore.  I've renamed the bug summary.

Setting the default assignee and QA Contact to "tomboy-maint@gnome.bugs".

I also experience this strange behaviour of linking words to non-existing notes.

I have found some explanation :

The bug seems to be in "Manager.TitleTrie.FindMatches"
which returns sometimes a hit pointing to NULL (causing tomboy to wrongly generate a link)

I checked this and added a test :
  if (hit.Value != NULL)
it fixed my problem.

in file watcher.cs : 
void HighlightInBlock (Gtk.TextIter start, Gtk.TextIter end)
{
	ArrayList hits = Manager.TitleTrie.FindMatches (start.GetSlice (end));
	foreach (TrieHit hit in hits) {
		if (hit.Value != null) { // ADDED
			DoHighlight (hit, start, end);
		} // ADDED
	}
}

I worked on the svn version Version 0.13.2, checked out 2009-01-12 15:52.

florian, this code has changed a bit since 0.13.2.  Please try latest SVN, and if you still experience a bug, submit a new patch following these instructions:

http://live.gnome.org/Tomboy/HowToSubmitPatches

One last thing; when you check out from SVN, the version number is not that useful.  Instead, use "svn info" from the top of your checkout to get the "Last Changed Rev".

Thanks!

Created attachment 127555 [details] [review]
Checks for hit==NULL in HighlightInBlock

The patch submitted test variable 'hit' in NULL value in HighlightInBlock and writes an error log instead of generating fake note links.
This is a work-around, the real bug seems to be in "Manager.TitleTrie.FindMatches" who gives NULL pointeur.

florian, your patch doesn't seem to fix the "auni buni cuni" problem described in comment #4.

What set of steps should I use to test your patch?

Indeed, the patch doesn't fix the "auni buni cuni" problem described
in comment #4.

The patch fixes the following problem :
When I type the word "voir" or "par" or some others,
a link is created to non-existing note (and hit.value == null).

As for testing the patch, I don't know how to reproduce this problem with a set of notes other than mine, sorry.

I don't think my patch should be included, "Manager.TitleTrie.FindMatches" should be investigated instead.

Created attachment 127754 [details] [review]
Checks validity of links before highlighting

I think this is a little better :

This patch checks the links in Watchers::DoHighlight before highlighting them, checks for null pointer, and hit pointing to non-existing or wrong notes.

This patch fixes the "auni buni cuni" problem described in
<a href="show_bug.cgi?id=323845#c4">comment #4</a>. 

To test it : see comment #4.

I worked on last rev 2318.

florian, thanks for the updated patch. I didnt' have time to review it before today's release, but I will look at it for the next one.

Florian, this patch seems to work great, and also fixes bug #531085 (for note links, at least).

I'm going to spend a little time playing with it to make sure we don't break any corner cases with it.  Can I have your full name so I can properly credit you for this?

Committed in r2348. Thanks Florian!

*** Bug 441215 has been marked as a duplicate of this bug. ***

*** Bug 494796 has been marked as a duplicate of this bug. ***

Wouah ! Cool, that's the first time my code will be actually used in a open project !
(my full name is Florian Pinault)