Delivered-To: lablgtk at yquem.inria.fr
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: =?iso-8859-1?Q?RE=A0=3A__=5BLablgtk=5D_Segfault_when_removing_or_setting_?=
	=?iso-8859-1?Q?an_invalid_GTree=2Eiter?=
Date: Mon, 4 Aug 2008 09:08:34 +0200
Message-ID: <5EFD4D7AC6265F4D9D3A849CEA9219190141AA at LAXA.intra.cea.fr>
Thread-Topic: [Lablgtk] Segfault when removing or setting an invalid GTree.iter
Thread-Index: Acj1sTxekoHlUZFrSCe2hNgzE0pG5gAS0cGh
References: <b6a766a0808031438h3d728aa5vf8cb5f2cbd0ee949 at mail.gmail.com>
From: "MONATE Benjamin 205998" <Benjamin.MONATE at cea.fr>
To: "Guillaume Brunerie" <guillaume.brunerie at gmail.com>
Cc: lablgtk at yquem.inria.fr
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 806

Hi,

> But shouldn't LablGTK raise an exception when a GTree.iter invalid is =
going
> to be used?

First, Gtk does not give any warranty that a critical error will be =
emitted before accessing an invalid iterator.
Second, the message is tiggered in the middle of a C function of Gtk. No =
exception can be raised properly from this context without changing the =
source of Gtk itself. The same problem exists with callbacks raising =
exceptions.
You may want to play with=20
Glib.Message.set_log_handler
  ~domain:"Gtk"
  ~levels:[ `CRITICAL] (fun ~level s -> prerr_endline s; exit 1);;
but any raised exception will be ignored.

Hope this helps,
Benjamin

_______________________________________________
Lablgtk mailing list
Lablgtk@yquem.inria.fr
http://yquem.inria.fr/cgi-bin/mailman/listinfo/lablgtk