This does not happen every time, but maybe 2 out of 3, suggesting a race condition.

Program received signal SIGSEGV, Segmentation fault.
0xb7a12b3f in queue_fam_event (monitor=0x8283a48, fam_event=0xbfe64380)
    at menu-monitor.c:192
192           event = tmp->data;
(gdb) bt

+ Trace 62603

$34 = {path = 0x2 <Address 0x2 out of bounds>, refcount = 0,
  notifies = 0x40280000, request = {reqnum = 1}, pending_events = 0x67903212,
  is_directory = 1}

I put a trace on unregister_monitor_with_fam() and discovered that the
MenuMonitor that causes the segfault has already been freed:

(gdb) b unregister_monitor_with_fam
Breakpoint 2 at 0xb79b2239: file menu-monitor.c, line 418.
(gdb) commands
Type commands for when breakpoint 2 is hit, one per line.
End with a line saying just "end".
>continue
>end
(gdb) r
Starting program: /usr/bin/python /usr/bin/gmenu-simple-editor
[Thread debugging using libthread_db enabled]
[New Thread -1208710720 (LWP 18311)]
Breakpoint 1 at 0xb7a130ca: file menu-monitor.c, line 369.
Breakpoint 2 at 0xb7a13239: file menu-monitor.c, line 418.
[Switching to Thread -1208710720 (LWP 18311)]
...
Breakpoint 2, unregister_monitor_with_fam (monitor=0x8283a48)
    at menu-monitor.c:418
418       if (failed_to_connect)
...
Program received signal SIGSEGV, Segmentation fault.
0xb7a12b3f in queue_fam_event (monitor=0x8283a48, fam_event=0xbfe64380)
    at menu-monitor.c:192
192           event = tmp->data;

I think what is happening is that when unregister_monitor_with_fam() calls 
FAMCancelMonitor() there are already unprocessed fam events in the queue that
have a pointer to the monitor, so when unregister_monitor_with_fam() returns and
the monitor is freed, queue_fam_event gets passed a freed monitor.

This is a race condition, so as noted above would not be triggered on every run.

The fix would be to run process_fam_events() immediately after
FAMCancelMonitor() to ensure any events with a pointer to the monitor get
processed before it is freed.

Note: running Gentoo fam-2.7.0-r4.