From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23675 invoked by alias); 18 Jun 2003 23:31:50 -0000 Mailing-List: contact guile-gtk-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: guile-gtk-owner@sources.redhat.com Received: (qmail 23605 invoked from network); 18 Jun 2003 23:31:49 -0000 Received: from unknown (HELO snoopy.pacific.net.au) (61.8.0.36) by sources.redhat.com with SMTP; 18 Jun 2003 23:31:49 -0000 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.2.228.40]) by snoopy.pacific.net.au (8.12.3/8.12.3/Debian-6.3) with ESMTP id h5INVlYd028790 for ; Thu, 19 Jun 2003 09:31:48 +1000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h5INVlQg001031 for ; Thu, 19 Jun 2003 09:31:47 +1000 (EST) Received: from localhost (ppp13.dyn228.pacific.net.au [203.143.228.13]) by wisma.pacific.net.au (8.12.9/8.12.9) with ESMTP id h5INVjnh006320 for ; Thu, 19 Jun 2003 09:31:45 +1000 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 19SmOW-000169-00; Thu, 19 Jun 2003 09:31:12 +1000 To: guile-gtk@sources.redhat.com Subject: GdkEvent copy under signal handler (was: Fixed memory leaks in gdk-1.2.defs) References: From: Kevin Ryde Mail-Copies-To: never Date: Wed, 18 Jun 2003 23:31:00 -0000 Message-ID: <87he6nezeo.fsf@zip.com.au> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-SW-Source: 2003-q2/txt/msg00143.txt.bz2 --=-=-= Content-length: 1559 Marko Rauhamaa writes: > > - gdk-1.2.defs: Removed copy options (previously: gdk_..._ref, > gtk_no_copy, gtk_fake_copy, gdk_..._copy). This included GdkEvent I take it. It's best to give the full name of each function and/or type, rather than "...", so they can be located by a grep etc. I believe this has introduced a bug in the handling of GdkEvent objects. An event passed to a signal handler is not copied, and can end up being freed while still in use. To observe this, add a fake version of gdk_event_free into guile-gtk.c void gdk_event_free (GdkEvent *e) { printf ("gdk_event_free %p\n", e); } And run a little program (use-modules (gtk gtk)) (define w (gtk-window-new 'toplevel)) (gtk-widget-add-events w '(pointer-motion-mask)) (define e #f) (gtk-signal-connect w "motion_notify_event" (lambda (event) (format #t "prev event ~a\n" e) (set! e event))) (gtk-widget-show-all w) (gtk-main) move the mouse across the window created. The output is something like gdk_event_free 0x80b1b7c prev event # 0x80b1b7c has been freed while it's still in the "e" variable. I propose to add back the copy option, * gdk-1.2.defs (GdkEvent): Reinstate copy option gdk_event_copy, and describe why it's there. I believe all functions which return a GdkEvent (namely gdk_event_get, gdk_event_peek, gdk_event_get_graphics_expose) have their own copyingness specified and are therefore unaffected by this change. --=-=-= Content-Disposition: attachment; filename=gdk-1.2.defs.gdk-event-copy.diff Content-length: 714 --- gdk-1.2.defs.~1.32.~ 2003-06-15 09:28:33.000000000 +1000 +++ gdk-1.2.defs 2003-06-15 15:33:29.000000000 +1000 @@ -407,7 +407,16 @@ (define-type-alias GdkBitmap GdkWindow) (define-type-alias GdkDrawable GdkWindow) +;; A GdkEvent passed to a signal handler is freed when the handler returns. +;; The copy option here ensures the boxed object we create from it has an +;; unlimited lifespan. +;; +;; For reference, the Gdk internal gdk_event_dispatch, which is a +;; GSourceFunc in the main loop, is where the freeing happens. An event is +;; dequeued, the handler function called, and the event freed. +;; (define-boxed GdkEvent + (copy gdk_event_copy) (free gdk_event_free)) (define-boxed GdkColor --=-=-=--