MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16091.1193.119501.516027 at karryall.dnsalias.org>
Date: Mon, 2 Jun 2003 10:02:49 +0200
From: Olivier Andrieu <andrieu at ijm.jussieu.fr>
To: Michael Welsh Duggan <md5i at cs.cmu.edu>
Cc: lablgtk at kaba.or.jp
Subject: Re: strange data problems
In-Reply-To: <87smqti1l9.fsf at cs.cmu.edu>
References: <874r3aemtx.fsf at cs.cmu.edu>
	<16090.34885.62505.554832@karryall.dnsalias.org>
	<87smqti1l9.fsf@cs.cmu.edu>

 Michael Welsh Duggan [Sunday 1 June 2003] :
 >
 > Olivier Andrieu <andrieu@ijm.jussieu.fr> writes:
 > 
 > >  Michael Welsh Duggan [Saturday 31 May 2003] :
 > >  >
 > >  > Using lablgtk2, the program at
 > >  > <URL:http://md5i.dsl.telerama.com:8000/timeagent/> fails under very
 > >  > strange circumstances.  Try compiling and running the program.  You
 > >  > should get a window that looks like
 > >  > <URL:http://md5i.dsl.telerama.com:8000/timeagent/ui1.png>.
 > >  > 
 > >  > Now, middle-click on the hex that is marked in 
 > >  > <URL:http://md5i.dsl.telerama.com:8000/timeagent/ui2.png>.  That
 > >  > should turn over the tile.  If you middle click on the tile again,
 > >  > the program segfaults.  I have been unable to determine why.  I am
 > >  > trying to create an isolated example, but I have not yet been able
 > >  > to.  
 > >
 > > OK I think it's a libgnomecanvas problem. 
 > >
 > > It's related to the way events for canvas items are handled. Canvas
 > > items are not widgets, so it's the canvas itself (a true GtkWidget)
 > > that intercepts events and forwards them to the appropriate items
 > > (according to the items hierarchy). On some occasions, the canvas
 > > itself synthetises ENTER/LEAVE notify events for canvas items but it
 > > does not initializes all the fields in the GdkEventCrossing structure,
 > > only the type, detail and subwindow fields (see
 > > gnome-canvas.c(pick_current_item) line 2693).
 > >
 > > That's what happening here. The bottom line is, some canvas item
 > > events are "faked" events and some of their fields are uninitialized
 > > (maybe because it wouldn't make any sense in the context of a canvas
 > > item ?). So access to these fields with lablgtk accessor fonctions is
 > > UB, just like in C.
 > 
 > I've considered that, and have poked around the libgnomecanvas code
 > myself under the debugger.  Unfortunately, I do not think that this
 > is what is happening in this circumstance.  For one,
 > pick_current_item does a very good job of filling the crossing event
 > data.  

You're right, I read the code too quickly, the problem isn't exactly
what I was saying. But I still think pick_current_item is to blame for
the corruption.

,----[ pick_current_item, line 2697 ]
| 		GdkEvent new_event;
| 		GnomeCanvasItem *item;
| 
| 		item = canvas->current_item;
| 		
| 		new_event = canvas->pick_event;
| 		new_event.type = GDK_LEAVE_NOTIFY;
| 
| 		new_event.crossing.detail = GDK_NOTIFY_ANCESTOR;
| 		new_event.crossing.subwindow = NULL;
| 		canvas->in_repick = TRUE;
| 		retval = emit_event (canvas, &new_event);
| 		canvas->in_repick = FALSE;
`----

Here the canvas->pick_event is copied into new_event but they do not
check if they have the same layout (ie if canvas->pick_event is a
GdkEventCrossing). If I add an assert in the code above :

   g_log("libgnomecanvas", G_LOG_LEVEL_DEBUG, 
         "canvas->pick_event.type = %d", canvas->pick_event.type);
   g_assert(canvas->pick_event.type == GDK_LEAVE_NOTIFY || 
            canvas->pick_event.type == GDK_ENTER_NOTIFY);

it fails with your program. It seems that canvas->pick_event is of
type GDK_BUTTON_PRESS which has a different layout than a
GdkEventCrossing (hence the corrupted fields).

(I'll try to have a closer look with a debugger)

-- 
   Olivier