Re: Gtk2 perl core dump

Thanks to Ross and muppet for the quick responses.

On Fri, Nov 26, 2004 at 08:36:10PM -0500, muppet wrote:

On Nov 26, 2004, at 6:39 PM, Ross McFarland wrote:

On Fri, 2004-11-26 at 11:31, Chris LaReau wrote:
I haven't gone much further looking into it as I'm fairly new to 
Gtk2, and haven't done much serious GUI programming since the era of 
the Motif/OpenLook turf wars, but I would appreciate any help or 
workarounds for this.

welcome to modern times.  gtk+ is much, much less painful to the brain 
than motif.  :-)

No doubt. It's also been much less painful to my brain than trying
to write my app in Mozilla; but a showstopper bug in that caused me
to look elsewhere, and then I accidentally came across the perl
bindings for Gtk+ (and Glade, which is what most of my actual
interface is done in, to avoid the hell of instantiating widgets in
hand-edited code), and thus to this...

i didn't track down exactly what was going on, but it's a pretty safe 
assumption that using add and remove on a vbox to change out widgets 
is dangerous.

it appears that it's not adding and removing widgets that is bad in and 
of itself, it's adding and removing widgets in the midst of a focus 
change sequence, when the widget you just removed is the next one in 
the sequence.  i added another entry widget between the two that were 
interacting, and the crash went away.  still, adding and removing 
widgets like this isn't necessary, since what you're wanting to do 
appears to be merely to change the label, and seeing widgets pop in and 
out of existence can seriously confuse users, so it's not really 
something you want to do.

What I was wanting to do was demonstrate the bug, so I stripped the
code down to (approximately) the bare essentials that would do that,
redoing the parent widgets in perl instead of Glade in the process.
I certainly wouldn't have done the add or remove if I had been able
to get by with setting a label. 

The actual application (an interface for efficiently entering
specialized metadata for images) replaces any previous contents of
the vbox with a list of checkboxes corresponding to a the results of
an SQL database search. Trust me, it really is something that I do
want to do. If such a thing was actually confusing to users, I doubt
that Google would be quite as popular as it is, given that it uses a
fundamentally identical interface.

For real-estate reasons, I do not want the checkboxes or the space
that they would take up to be there when no checkboxes are active.

this sensitizes the checkbutton whenever it has a label; you could just 
as easily hide and show it if you really need the widget to disappear.

I tried a lot of different combinations of stuff to try and work
around the problem:

* hide() appeared to do nothing at all.

* remove() and destroy() both coredumped. 

* set_child_visible(), realized(), unmap() made the widget
      disappear except that it still took up space in the parent.

as far as finding the underlying bug (assuming that seg faults should 
never happen no matter whether the program is behaving or not.)  
translating to C and running that should tell you if it has 
anything to do with Gtk2. if it doesn't then filing a bug in gnome 
bugzilla with the attached C program would be the appropriate next 

here's a quick C port (see attached dumpage.c, especially if you want 
to remind yourself why gtk2-perl is so much better than gtk+ in C).  it 
exhibits similar behavior, but with a bunch of assertions about a bad 
object before actually crashing -- sometimes.

in both cases (c and perl), it appears to be a misuse of gtk+ that 
causes the crash.  by the time you get into the focus-out handler the 
second time, gtk+ wants to give the keyboard focus to the next widget 
in the focus chain, which you have just removed.  this causes gtk+ to 
try to dereference a pointer that has already been freed, which results 
in the badness you know so well.  note in the that i attached, 
even though the checkbutton is desensitized in the focus-out handler, 
it still gets keyboard focus.  this hints to what i can't seem to find 
in the gtk+ source -- that the list of children involved in the focus 
chain is grabbed before the invocation of the handler for focus-out on 
your widget.  it would be worth mentioning this to the gtk+ developers, 
as it suggests some sort of underlying problem in the focus chain code.

Thank you very much for the C translation. It would have involved a
fair bit of work on my part to do that as I have yet to write any
Gtk+ code in C, and I may need to do that to get to the bottom of
this problem.

In any event, I was simply using the focus out event as a convenient
way to trigger the search; I would probably rather trigger it some
other way, but I don't have enough experience with the Entry widget
to figure out how to add a control key or something of the sort that
would trigger a user event and not interfere with the normal
operation of the widget. If the code did work, though, it would be
desirable for the first new checkbox to get the focus once all the
search result widgets were created.

Thanks for all your help. I'll see how I fare with the gtk+



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]