Re: balsa crash identified



Last one, I promise :)

It seems that when the "cross on top window" is clicked, the signal
"destroy" is sent to the main window. What I understand, is that all
subwidget are destroyed.

The BaslaMessage widget corresponding to the message selected is also
destroyed, and thus it's memory released. But at one time, the
message_destroyed_cb set for the LibBalsaMessage selected is scheduled,
with the BalsaMessage as parameter. As this BalsaMessage doesn't exist
anymore this lead to a SIGSEGV...

So looking at src/main-window.c and function balsa_window_destroy, I
change the following piece of code :

  if (GTK_OBJECT_CLASS(parent_class)->destroy)
    (*GTK_OBJECT_CLASS(parent_class)->destroy)(GTK_OBJECT(object));

  /* don't try to use notebook later in empty_trash */
  balsa_app.notebook = NULL;
  balsa_exit();

into 

  /* don't try to use notebook later in empty_trash */
  balsa_app.notebook = NULL;
  balsa_exit();

  if (GTK_OBJECT_CLASS(parent_class)->destroy)
    (*GTK_OBJECT_CLASS(parent_class)->destroy)(GTK_OBJECT(object));


And it seems to fix the problem :)

Best Regards.


Frederick Ros wrote:
> 
> Once again,
> using balsa with glib-1.2.8 configured with --enable-mem-check doesn't
> cause the ending SIGSEGV ...
> And it seems me that the difference is that in g_free the are of memory
> freed is previously set to 0...
> 
> --
> Frederick Ros
> Ulticom, Inc
> Phone: +33.497.234.520
> Frederick.Ros@ulticom.com
> 
> _______________________________________________
> balsa-list mailing list
> balsa-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/balsa-list

-- 
Frederick Ros
Ulticom, Inc
Phone: +33.497.234.520
Frederick.Ros@ulticom.com




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