(I've changed the subject because I take a left turn into gdb-land in the
middle of this message.)
James> I may as well add that one of the aims is to never (or at least
James> hardly ever) spit out these gtk warnings. Many of the type
James> checks that might spit out these warnings are already caught as
James> exceptions (mainly type checks).
It seems to me that even when pygtk is perfect, the programmer will still be
able to make mistakes when manipulating Gtk objects, so these warnings are
still going to be present, it's just that they will be the programmer's
problem, not yours.
James> If you can track down where the warning occurs, please file a bug
James> report (they generally indicate an error in the program which
James> could cause a segfault if assertions were turned off in gtk).
I would, but at this point it's difficult to tell if I'm doing something
wrong or there is an underlying problem with pygtk or gtk itself. I'm just
not familiar enough with everything.
I still think it would be useful to be able to turn these things into
exceptions. In response to Matt's "it can't be done" response: I will never
use Gtk threads in my Python code (preferring Python's threads instead),
will generally not use threads anyway (most code doesn't need it), and when
I do will only make Gtk calls from one thread, so for me it makes sense to
couple Gtk's warning/error messages with Python's exception handling
mechanism, even if just to be able to print out a Python traceback for
debugging purposes. It seems to me that most people will constrain their
Python/Gtk code structure in similar ways.
(Skip makes the signal for a left turn.)
One thing I do find rather odd, however, is that in some situations I get no
warnings, but when running under gdb (same shared libraries, same python
executable, same scripts), get several Gtk messages. To wit:
% PYTHONPATH=.. python List.py
Gtk-Message: YOU ARE USING THE DEVEL BRANCH 1.3.x OF GTK+ WHICH IS CURRENTLY
UNDER HEAVY DEVELOPMENT AND FREQUENTLY INTRODUCES INSTABILITIES.
if you don't know why you are getting this, you probably want to
use the stable branch which can be retrieved from
ftp://ftp.gtk.org/pub/gtk/v1.2/ or via CVS with
cvs checkout -r glib-1-2 glib; cvs checkout -r gtk-1-2 gtk+
['__class__', '__cmp__', '__delattr__', '__dict__', '__getattribute__',
'__gobject_init__', '__gtype__', '__hash__', '__init__', '__new__', '__reduce__',
'__repr__', '__setattr__', '__str__', 'connect', 'connect_after', 'connect_object',
'connect_object_after', 'destroy', 'disconnect', 'emit', 'emit_stop_by_name', 'flags',
'freeze_notify', 'get_data', 'get_property', 'get_selected', 'handler_block',
'handler_disconnect', 'handler_unblock', 'notify', 'ref', 'remove_data',
'remove_no_notify', 'select_all', 'select_iter', 'select_path', 'select_range',
'selected_foreach', 'set_data', 'set_flags', 'set_mode', 'set_property', 'sink',
'stop_emission', 'thaw_notify', 'unref', 'unselect_all', 'unselect_iter',
'unselect_path', 'unset_flags']
Segmentation fault
Okay, we have a problem. Suppose I'd like to debug that segfault. Let's
try gdb:
% type python
python is hashed (/usr/local/bin/python)
% gdb /usr/local/bin/python
GNU gdb 5.0mdk-11mdk Linux-Mandrake 8.0
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-mandrake-linux"...
(gdb) set env PYTHONPATH ..
(gdb) r List.py
Starting program: /usr/local/bin/python List.py
[New Thread 1024 (LWP 7124)]
Gtk-Message: YOU ARE USING THE DEVEL BRANCH 1.3.x OF GTK+ WHICH IS CURRENTLY
UNDER HEAVY DEVELOPMENT AND FREQUENTLY INTRODUCES INSTABILITIES.
if you don't know why you are getting this, you probably want to
use the stable branch which can be retrieved from
ftp://ftp.gtk.org/pub/gtk/v1.2/ or via CVS with
cvs checkout -r glib-1-2 glib; cvs checkout -r gtk-1-2 gtk+
List.py (pid:7124): GRuntime-CRITICAL **: file gparamspecs.c: line 1521
(g_param_spec_float): assertion `default_value >= minimum && default_value <= maximum'
failed
List.py (pid:7124): GRuntime-CRITICAL **: file gobject.c: line 270
(g_object_class_install_property): assertion `G_IS_PARAM_SPEC (pspec)' failed
List.py (pid:7124): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to
allocate widget with width -2147483648 and height 12
['__class__', '__cmp__', '__delattr__', '__dict__', '__getattribute__',
'__gobject_init__', '__gtype__', '__hash__', '__init__', '__new__', '__reduce__',
'__repr__', '__setattr__', '__str__', 'connect', 'connect_after', 'connect_object',
'connect_object_after', 'destroy', 'disconnect', 'emit', 'emit_stop_by_name', 'flags',
'freeze_notify', 'get_data', 'get_property', 'get_selected', 'handler_block',
'handler_disconnect', 'handler_unblock', 'notify', 'ref', 'remove_data',
'remove_no_notify', 'select_all', 'select_iter', 'select_path', 'select_range',
'selected_foreach', 'set_data', 'set_flags', 'set_mode', 'set_property', 'sink',
'stop_emission', 'thaw_notify', 'unref', 'unselect_all', 'unselect_iter',
'unselect_path', 'unset_flags']
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 7124)]
0x401be364 in g_object_get_qdata (object=0xbfffdf50, quark=46)
at gobject.c:1328
1328 g_return_val_if_fail (G_IS_OBJECT (object), NULL);
(gdb)
Where did those messages come from??? I do get the segfault, so I have some
data to help debugging, but my confidence in the robustness of the overall
system is somewhat shaken by the presence of these Gtk messages only when
the script is run under gdb.
Where are those messages emitted in relation to my code? I do have a little
gdb hack that some may find helpful in these situations, but it's a pain in
the butt to use, largely because gdb never reenables breakpoints in shared
libraries. Here's the gdb code:
define ppystack
set $__fr = 0
select-frame $__fr
while $pc < Py_Main || $pc > Py_GetArgcArgv
if $pc > eval_frame && $pc < PyEval_EvalCodeEx
set $__fn = PyString_AsString(co->co_filename)
set $__n = PyString_AsString(co->co_name)
printf "%s (%d): %s\n", $__fn, f->f_lineno, $__n
end
up-silently 1
end
select-frame 0
end
It emits lines like
(gdb) ppystack
List.py (53): set_choices
List.py (16): __init__
List.py (81): _test
<stdin> (1): ?
Assuming you want to use it whenever g_log is called, you need to run the
Python interpreter, import gtk, C-c back to gdb, set (or enable) the
breakpoint in g_log, continue, then execute whatever code leads you into
g_log. At that point you can execute ppystack to get the mini stack trace I
showed above. The reason for all this rigamarole is that once a program
starts, gdb disables breakpoints that were set in shared libraries, and
doesn't reenable them once the shared library is loaded. (If there's a way
to get it to do that, I'm all ears.)
Now, wouldn't it be a lot easier if I could just register a handler that
raised an exception when gtk encountered a problem? ;-)
even-if-it-didn't-always-work-ly y'rs,
Skip
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
