[Texmacs-dev] GCC 3.2 segfaults...

[Igor V. Kovalenko]

Igor V. Kovalenko wrote:
> Igor V. Kovalenko wrote:
>
> > Joris van der Hoeven wrote:
> >
> > > But now I am again confused, because the old routine
> > > destroy_tree_rep should precisely do the same thing
> > > as the virtual destructor. Apparently, a string is sometimes
> > > not a string or a compound not a compound...
> >
> >
> >
> > Indeed, this is rather clever idea :)
> >
> > I'm currently investigating the effect of GCC/c++ PR 8287
> > "GCC3.2: Destructor called for non-constructed local object"
> >
> > I'll follow up on this shortly.
>
> Well, It takes time to rebuild GCC :)
>
> The file attached contains the verification code. It does introduce an
> extra unsigned long field to tree and string classes. Their constructors
> do initialize this field to magic value 0xF9CC8287LU and destructors
> check for this value before proceeding. If the object is indeed constructed
> the value is set to 0xDEADBEEFLU.
Well, OK, destructor proceeds and sets the value to be 0xDEADBEEFLU.

> A test run is as follows. Compile with GCC-3.2 using all default 
> optimizations.
> Then execute and press F1. Try to select some large region of text.
>
> You should see:
>
> --------------------------------------
> .....
> TeXmacs] Loading ecbx7 at 600 dpi
> TeXmacs] Loading rtcxr10 at 600 dpi
> TeXmacs] Loading rtcxr0.tfm
> TeXmacs] Loading rtcxr10.tfm
> TeXmacs] Loading rtcxr10.600pk
> TeXmacs] Loading ecrm8 at 600 dpi
> TeXmacs] Loading ecrm6 at 600 dpi
> TeXmacs] Loading cmr6 at 600 dpi
> TeXmacs] Running ghostscript 
> /usr/share/TeXmacs-1.0.0.21/misc/images/tm_gnu1.ps
> TeXmacs] Running ghostscript 
> /usr/share/TeXmacs-1.0.0.21/misc/images/tm_gnu2.ps
> dtor_tree magic: deadbeef
> [aborted, core dumped]
> --------------------------------------
>
> If you don't see this, you should wait for auto-save and repeat F1 and 
> selection action.
>
> Now I'm in a little confusion :)
>
> There are at least two possibilities:
>    1. TeXmacs is affected by GCC/c++ PR 8287. I wrote this test exactly 
>       to show this :)
>    2. There does exist some double-deletion of tree object.
>
> The point of confusion is that I rebuilt TeXmacs, GCC-3.2 (20021021) and 
> libstdc++ using
> a patch described in PR 8287 FIX 
> (http://gcc.gnu.org/ml/gcc-patches/2002-10/msg01817.html)
> and still I'm able to reproduce the problem.
>
> Anyway, there was a fix re: PR 8287 implemented in GCC-3.2 CVS on 20021029.
> It's a pity some major distributions shipped a compiler with such a bug.
> It's even described as 'lethal' within PR 8287 :) I agree, this usage 
> pattern is quite common.
>
> I'm now rebuilding with GCC-3.2 snapshot 20021104 (the latest available) 
> and
> will come up with the result.

Now I'm using GCC-3.2 20021107 from CVS which is 20021104 plus minor 
modifications.
This version does contain a fix for GCC/c++ PR 8287.

The test described in my previous mail shows the same behaviour, i.e. some tree 
object
must have been deleted more than once.

I'm unable to reproduce this in non-optimized build. Also the bug seems to be 
unrelated
to auto_save (i.e. reproducible without).

Anyone have any ideas?

Anyway, everyone using GCC-3.2 should be advised to use GCC-3.2 older than 
20021029
to eliminate a very obscure bug with destructors. Or wait for GCC-3.2.1 which 
should be
released in a couple of weeks.

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