MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16090.34885.62505.554832 at karryall.dnsalias.org> Date: Mon, 2 Jun 2003 01:12:05 +0200 From: Olivier Andrieu To: Michael Welsh Duggan Cc: lablgtk at kaba.or.jp Subject: Re: strange data problems In-Reply-To: <874r3aemtx.fsf at cs.cmu.edu> References: <874r3aemtx.fsf at cs.cmu.edu> Michael Welsh Duggan [Saturday 31 May 2003] : > > Using lablgtk2, the program at > fails under very > strange circumstances. Try compiling and running the program. You > should get a window that looks like > . > > Now, middle-click on the hex that is marked in > . 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. By looking quickly at the gnome-canvas code, I think it's concerns only LEAVE/NOTIFY events. The problem is that I don't know how to distinguish the "complete" crossing events (with all their fields initialized) and those with uninitialized fields. -- Olivier