Problem with global destruction

I have an application, which uses Gtk2 and other modules,
which use 
linked libraries. In Windows (not in Linux, but I'm not sure
if that 
means anything) I have a problem in global desctruction. If
I close the 
app without doing anything everything is ok, but if I do
something which 
creates an object that is shown graphically also, and then
close the app 
I get "Program Error" that says "perl.exe has
generated errors and will 
be closed by windows...". The error happens in the
global destruction. 
I've tried to catch the problem with a debugging perl, but
the problem 
does not appear if I run the app with -DD.

I'm running out of things to try. Does anybody here have any
tips or ideas?

Ari

-- 
Prof. Ari Jolma
Geoinformaatio- ja paikannustekniikka
Geoinformation and positioning technology
Teknillinen Korkeakoulu / Helsinki University of Technology
POBox 1200, 02015 TKK, Finland
Email: ari.jolma at tkk.fi URL: http://www.tkk.fi/~jolma


_______________________________________________
gtk-perl-list mailing list
gtk-perl-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-perl-list

I debugged this a bit further,

This may be because of a "Access violation" error
in 
g_signal_has_handler_pending (dependencywalker gives a hint
to this 
direction). I see quite a lot of bug report pages when
googling with 
these words. What could be the cause (in my code) of such a
situation?


Ari Jolma kirjoitti:
> I have an application, which uses Gtk2 and other
modules, which use 
> linked libraries. In Windows (not in Linux, but I'm not
sure if that 
> means anything) I have a problem in global
desctruction. If I close the 
> app without doing anything everything is ok, but if I
do something which 
> creates an object that is shown graphically also, and
then close the app 
> I get "Program Error" that says
"perl.exe has generated errors and will 
> be closed by windows...". The error happens in the
global destruction. 
> I've tried to catch the problem with a debugging perl,
but the problem 
> does not appear if I run the app with -DD.
>
> I'm running out of things to try. Does anybody here
have any tips or ideas?
>
> Ari
>
>   


-- 
Prof. Ari Jolma
Geoinformaatio- ja paikannustekniikka
Geoinformation and positioning technology
Teknillinen Korkeakoulu / Helsinki University of Technology
POBox 1200, 02015 TKK, Finland
Email: ari.jolma at tkk.fi URL: http://www.tkk.fi/~jolma


_______________________________________________
gtk-perl-list mailing list
gtk-perl-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-perl-list

That sounds a bit strange. I have already written and tested
a lot of 
things under Win32 and never got anything like that.

Could you provide us with the sourcecode that caused the
error?

Greetings,
Mario
_______________________________________________
gtk-perl-list mailing list
gtk-perl-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Mario Fischer kirjoitti:
> That sounds a bit strange. I have already written and
tested a lot of 
> things under Win32 and never got anything like that.
> 
> Could you provide us with the sourcecode that caused
the error?


That could be a bit difficult, the whole system is quite
large and I get
the error only in mingw environment. I've got the previous
versions
available at http://map.hut.fi/files/
(~20MB packages including a
complete Perl but not the GTK libraries) but I see the
problem with
those very rarely. The problems maybe related to updating
Glib and Gtk2
to latest versions (from 1.140 to 1.144).

As I wrote this morning, the dependencywalker software seems
to point to
the g_signal_has_handler_pending function in libgobject.
I've got a
subclass (created with Glib::Object::Subclass) of
Gtk2::ScrolledWindow
in the code and it seems that the error comes only if an
object of that
class is created and used. I've defined two new signal types
for the object.

Ari


> 
> Greetings,
> Mario
> _______________________________________________
> gtk-perl-list mailing list
> gtk-perl-listgnome.org
> 
http://mail.gnome.org/mailman/listinfo/gtk-perl-list


-- 
Prof. Ari Jolma
Geoinformaatio- ja paikannustekniikka / Geoinformation and
positioning
Teknillinen Korkeakoulu / Helsinki University of Technology
tel: +358 9 451 3886 address: POBox 1200, 02015 TKK,
Finland
Email: ari.jolma at tkk.fi URL: http://www.tkk.fi/~jolma

_______________________________________________
gtk-perl-list mailing list
gtk-perl-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-perl-list

I wrote:
> class is created and used. I've defined two new signal
types for the object.
>   

I tried commenting out every line of code which has
something to do with 
signals and it turns out that if I connect the size_allocate
signal to a 
function (this is in sub INIT_INSTANCE of the subclass of 
Gtk2::ScrolledWindow):

$self->->signal_connect(size_allocate =>
&size_allocate, $self);

the problem appears. The $self-> is created in the
INIT_INSTANCE 
function and it is never destroyed, in sub render it is set
from a new 
pixmap:

$self->->set_from_pixbuf(undef);
$self->->set_from_pixmap($self->,und
ef);

The size_allocate is like this:

sub size_allocate {
    my($image,$allocation,$self) = _;
    my old_v = (0,0);
    old_v = {$self->} if
$self->;
    my v = $allocation->values;
    {$self->} = v[2..3];
    $self->render() if $v[2] != $old_v[0] or $v[3] !=
$old_v[1];
    return 0;
}

Ari

-- 
Prof. Ari Jolma
Geoinformaatio- ja paikannustekniikka
Geoinformation and positioning technology
Teknillinen Korkeakoulu / Helsinki University of Technology
POBox 1200, 02015 TKK, Finland
Email: ari.jolma at tkk.fi URL: http://www.tkk.fi/~jolma


_______________________________________________
gtk-perl-list mailing list
gtk-perl-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Ari Jolma wrote:
> I wrote:
>> class is created and used. I've defined two new
signal types for the object.
>>
>
> I tried commenting out every line of code which has
something to do with
> signals and it turns out that if I connect the
size_allocate signal to a
> function (this is in sub INIT_INSTANCE of the subclass
of
> Gtk2::ScrolledWindow):
>
> $self->->signal_connect(size_allocate
=> &size_allocate, $self);
>
> the problem appears.

At first blush, it sounds like you have created a reference
leak.  (This is
far from definitive, but that's what it sounds like.)

Try overriding the destroy signal (NOT the DESTROY method,
but the "destroy"
signal!!) on your ScrolledWindow subclass, and in there,
disconnect the signal
and destroy the child.

 # INIT_INSTANCE
   # keep the handler id so we can disconnect it later
   $self-> =
        $self->->signal_connect(size_allocate
=> &size_allocate, $self);

 # do_destroy
   # disconnect the handler added in INIT_INSTANCE to break
the ref cycle
   $self->->signal_handler_disconnect
($self->);
   # chain up, so that the rest of the destruction happens
properly
   $self->signal_chain_from_overridden (_);
   # release our own reference (may not be strictly
necessary)
   delete $self->;



-- 
muppet <scott at asofyet dot org>

_______________________________________________
gtk-perl-list mailing list
gtk-perl-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-perl-list

muppet kirjoitti:
> Ari Jolma wrote:
>   
>> I tried commenting out every line of code which has
something to do with
>> signals and it turns out that if I connect the
size_allocate signal to a
>> function (this is in sub INIT_INSTANCE of the
subclass of
>> Gtk2::ScrolledWindow):
>>
>> $self->->signal_connect(size_allocate
=> &size_allocate, $self);
>>
>> the problem appears.
>>     
>
> At first blush, it sounds like you have created a
reference leak.  (This is
> far from definitive, but that's what it sounds like.)
>
> Try overriding the destroy signal (NOT the DESTROY
method, but the "destroy"
> signal!!) on your ScrolledWindow subclass, and in
there, disconnect the signal
> and destroy the child.
>   

Couldn't do that, the signal seems to connect (it returns an
integer) 
but does not get called (I tried signals "destroy"
and "destroy_event"). 
However, I can call the do_destroy (below) from the close
subroutine of 
the main window. But that does seem to help :(

Ari

>  # INIT_INSTANCE
>    # keep the handler id so we can disconnect it later
>    $self-> =
>        
$self->->signal_connect(size_allocate =>
&size_allocate, $self);
>
>  # do_destroy
>    # disconnect the handler added in INIT_INSTANCE to
break the ref cycle
>    $self->->signal_handler_disconnect
($self->);
>    # chain up, so that the rest of the destruction
happens properly
>    $self->signal_chain_from_overridden (_);
>    # release our own reference (may not be strictly
necessary)
>    delete $self->;
>
>
>
>   


-- 
Prof. Ari Jolma
Geoinformaatio- ja paikannustekniikka
Geoinformation and positioning technology
Teknillinen Korkeakoulu / Helsinki University of Technology
POBox 1200, 02015 TKK, Finland
Email: ari.jolma at tkk.fi URL: http://www.tkk.fi/~jolma


_______________________________________________
gtk-perl-list mailing list
gtk-perl-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-perl-list

On Mon, 2007-03-19 at 19:17 +0200, Ari Jolma wrote:

> > Try overriding the destroy signal (NOT the DESTROY
method, but the "destroy"
> > signal!!) on your ScrolledWindow subclass, and in
there, disconnect the signal
> > and destroy the child.
> >   
> 
> Couldn't do that, the signal seems to connect (it
returns an integer) 
> but does not get called (I tried signals
"destroy" and "destroy_event"). 
> However, I can call the do_destroy (below) from the
close subroutine of 
> the main window. But that does seem to help :(

if the destroy signal never gets called, it seems that the
image never
gets destroyed.

try adding a FINALIZE method in your Gtk2::ScrolledWindow
subclass, and
explicitely remove the image:

  sub FINALIZE {
    my ($self) = _;

    warn "Inside finalizen";

    $self->remove($self->);
    delete $self->; # this should not be needed
  }

ciao,
 Emmanuele.

-- 
Emmanuele Bassi,  E: ebassigmail.com
W: http://www.emmanuelebas
si.net
B: http://log.emmanuelebas
si.net

_______________________________________________
gtk-perl-list mailing list
gtk-perl-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-perl-list

On Mon, 2007-03-19 at 17:23 +0000, Emmanuele Bassi wrote:

> 
> try adding a FINALIZE method in your
Gtk2::ScrolledWindow subclass, and
> explicitely remove the image:
> 
>   sub FINALIZE {
>     my ($self) = _;
> 
>     warn "Inside finalizen";
> 
>     $self->remove($self->);
>     delete $self->; # this should not be
needed
>   }

sorry, it's FINALIZE_INSTANCE.  too much coding in C. 

ciao,
 Emmanuele.

-- 
Emmanuele Bassi,  E: ebassigmail.com
W: http://www.emmanuelebas
si.net
B: http://log.emmanuelebas
si.net

_______________________________________________
gtk-perl-list mailing list
gtk-perl-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-perl-list

hmm, I updated to the latest (2.12.11) libgobject-2.0.0.dll
from 
ftp://ftp.gtk.org/pub/glib/2.10 (I was using 2.10.7(?) which
is 
available from http:
//gladewin32.sourceforge.net/modules/news/)

and the problem disappeared...

Ari

muppet kirjoitti:
> Ari Jolma wrote:
>   
>> I tried commenting out every line of code which has
something to do with
>> signals and it turns out that if I connect the
size_allocate signal to a
>> function (this is in sub INIT_INSTANCE of the
subclass of
>> Gtk2::ScrolledWindow):
>>
>> $self->->signal_connect(size_allocate
=> &size_allocate, $self);
>>
>> the problem appears.
>>     
>
> At first blush, it sounds like you have created a
reference leak.  (This is
> far from definitive, but that's what it sounds like.)
>
> Try overriding the destroy signal (NOT the DESTROY
method, but the "destroy"
> signal!!) on your ScrolledWindow subclass, and in
there, disconnect the signal
> and destroy the child.
>   

Couldn't do that, the signal seems to connect (it returns an
integer)
but does not get called (I tried signals "destroy"
and "destroy_event").
However, I can call the do_destroy (below) from the close
subroutine of
the main window. But that does seem to help :(

Ari

>  # INIT_INSTANCE
>    # keep the handler id so we can disconnect it later
>    $self-> =
>        
$self->->signal_connect(size_allocate =>
&size_allocate, $self);
>
>  # do_destroy
>    # disconnect the handler added in INIT_INSTANCE to
break the ref cycle
>    $self->->signal_handler_disconnect
($self->);
>    # chain up, so that the rest of the destruction
happens properly
>    $self->signal_chain_from_overridden (_);
>    # release our own reference (may not be strictly
necessary)
>    delete $self->;
>
>
>
>   


-- 
Prof. Ari Jolma
Geoinformaatio- ja paikannustekniikka
Geoinformation and positioning technology
Teknillinen Korkeakoulu / Helsinki University of Technology
POBox 1200, 02015 TKK, Finland
Email: ari.jolma at tkk.fi URL: http://www.tkk.fi/~jolma



_______________________________________________
gtk-perl-list mailing list
gtk-perl-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-perl-list