Re: [Texmacs-dev] [PATCH] solves GCC 3.2 auto_save segfault for me...

[Igor V. Kovalenko]

Joris van der Hoeven wrote:
> > I tested TeXmacs with the patch included and it seems to be stable now.
> > Comments?
>
>
> I also tested your patch now and, unfortunately,
> I still get segfaults just after autosaving and typing a bit of text.
>
> I also restudied the use of virtual destructors.
> In fact, the current implementation is correct and best.
> Indeed, you should not forget that a virtual destructor increases
> the size of the data structure. Consequently, one should avoid
> the use of it whenever possible.

Agreed.

> >  struct concrete_struct {
> >    int ref_count;
> >    inline concrete_struct (): ref_count (1) { DEBUG(concrete_count++); }
> > -  inline ~concrete_struct () { DEBUG(concrete_count--); }
> > +  inline virtual ~concrete_struct () { DEBUG(concrete_count--); }
> >  };
>
>
> The classes concrete_struct and abstract_struct are really base classes
> and *not* abstract classes: we never explicitly allocate a concrete_struct
> or an abstract_struct. Moreover, the destructor does nothing when DEBUG
> is inactive. We might just add "DEBUG(virtual)" to be extremely correct.

In my opinion this "virtualization" has an effect to make all destructors
in derived classes virtualized, so pointer can be deleted without explicitly
accessing the data.

> > +inline tree::~tree ()
> > +{
> > +    if ((--rep->ref_count)==0) {
> > +        //destroy_tree_rep (rep);
> > +        delete rep;
> > +        rep = NULL;
> > +    }
> > +}
>
>
> Again, the function destroy_tree_rep explicitly does the "delete rep"
> depending on the kind of tree (string or compound). Indeed, this type
> can be determined as a function of "op", so destroy_tree_rep plays
> the rôle of a virtual destructor *without* the extra space overhead.
> It may still be interesting though to add the line "rep = NULL"
> to destroy_tree_rep.

Nope, it does a wild cast do destruct an object. Correct?

What binutils version are you using? I'm now in deep confusion :) Mine is:

$ ld -V
GNU ld version 2.13.90.0.10 20021010
  Supported emulations:
   elf_i386
   i386linux
   elf_i386_glibc21

I simply want to find a difference. Tests show that guile is probably not 
guilty...

--
Regards,
Igor V. Kovalenko    mailto: iko at crec dot mipt dot ru