texmacs-dev
[Top][All Lists]
Advanced

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

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


From: Joris van der Hoeven
Subject: Re: [Texmacs-dev] [PATCH] solves GCC 3.2 auto_save segfault for me...
Date: Fri, 8 Nov 2002 18:39:10 +0100 (MET)

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

Hmmm, option 2 would not surprise me;
it took me one week of debugging to find this bug in g++-3.0.
It somehow disappeared from 3.1, but they seem to be uncautious enough
to let it reappear in other major distributions. I think that this is
a shame, because it is an awefully difficult task to localize such bugs
in large programs. Even if one manages to localize the bug, it is not
always clear how to fix it. I managed to produce a fix in the above
case of g++-3.0, but then the same problem arose somewhere else...;
it is an impossible task to systematically hunt these bugs down.

So it seems that we should strongly advice people not to use
the g++-3.* series until they prove to be able to release
a stable and trustworthy compiler.

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

Thanks, it would be great to know whether hypothesis 2 is right...
If you can find a systematic way of testing whether this bug has
reappeared in g++, then that would even be better.

I also hope to provide a compilation option which will enable
you to use Hans Boehme's conservative garbage collection scheme
instead of the TeXmacs memory allocator. I can not promise a date,
because we have many other urgent projects, but the advantage of
Boehme's gc is that destructors become no-ops and that the gc
automagically detects unused memory. In other words, if the bug
is due to a double call of a destructor, then that won't harm anymore...
The problem is that I did not yet study the interaction
with Guile in detail.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]