[Texmacs-dev] GCC-3.2 segfault debugging update

[David Allouche]

For the last two days, I have been playing with valgrind (Joris: I
know, that is not what I am supposed to do at the moment) because that
question about aliasing violations (which do not seem to actually
exists) tickled my curiosity.

So here is the summary of my experience:

For one thing, on my debian system, I had to build valgrind from
source by hand (using debianized source, though) because otherwise it
had a failure because of incompatible libc version number. But that is
not really of general interest.

Guile does raise a big mass of false positives in its stack walking
code. However Valgrind has a nice suppression feature which make it
easy to weed them out. My suppression file is attached to this email,
it also suppress some Xlib hits which seem caused by problems in my
Xlib installation and/or in Valgrind.

Debugging must be done with Joris' fast_alloc disabled. The way to do
it is to comment out the declarations of new, new[], delete and
delete[] in basic.hh. I guess we might add a configure option to make
this easier. The reason is not distrust in the allocation code, but
simply that it may hide problems from Valgrind. With that code
disabled all malloc's and free's are properly monitored by Valgrind,
so problems can be detected earlier.

One exemple is the once reported "w/o fast_alloc it crashes once I
click the window. Actually the problem is caused by a double
destruction of a counted pointer "list" in "find_accessible_child"
called from "find_box_path". With fast_alloc enabled it does not crash
(and is not reported by valgring) but probably corrupts the fast_alloc
stuff is subtle ways.

I was able to work around that particular bug by modifying the
refcounting macros in basic.hh. I added a bool data member called
"destroyed" which was set to "false" at creation, and set to "true" at
destruction, and immediately returned from ~list (and other
destructors using the same macro, by the way) before handling
refcounting if "destroyed" was true. That fix is too ugly to get into
mainline but it is instructive.

I also was able to reproduce the autosave crash. It seems to be caused
by multiple destruction of a tree object when returning from an inner
"tm_writer::write" call directly into "tm_data_rep::save_tree(string,
tree, bool)", but only occurs if save_tree is called from
"tm_data_rep::auto_save()"! Though such a return path does not exist
in the code but the optimizer reschedule things.

Also, I detected a missing initialization in as_double(string). It
does not seem to cause any problem at the moment, I will post the
patch later.

I was doing my tests with a binary produced with "-O -ggdb". At a
moment I found that inlining made tracing the code very difficult, so
I disabled it. Then...

Surprise! Compiling with "-ggdb -O -fno-default-inline -fno-inline"
(maybe -fno-default-inline is redundant...) with g++-3.2 produces a
executable which run perfectly well!!!

I had one user (d33p on #texmacs) compile and test an executable
compiled after './configure --enable-optimize="-O3
-fexpensive-optimizations -fno-default-inline -fno-inline"' with
g++-3.2 and it seems that produces binary which is much faster than
w/o optimizations and which DOES NOT CRASH.

So, please test this compilation setting and tell me how it works.

Final question: can anyone tell how to enable no optimization *but*
inlining... so we can further track the problem.

-- 
David Allouche         | GNU TeXmacs -- Writing is a pleasure
Free software engineer |    http://www.texmacs.org
   http://ddaa.net     |    http://alqua.com/tmresources
   address@hidden  |    address@hidden
TeXmacs is NOT a LaTeX front-end and is unrelated to emacs.

texmacs.supp
Description: Text document