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.
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.