Re: [Texmacs-dev] GCC-3.2 segfault debugging update

[Igor V. Kovalenko]

David Allouche wrote:
> 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.

I tried to track guile false positives some time ago :) Some led me to
uninitialized values in TeXmacs own code. But they should be detectable
anyway. It's nice you have these suppressions ready.

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

This should not happen if I correctly understand the thing of side effects.
I see this return path as it should be created by GCC bug.
Do you use GCC-3.2.1 (release) version?

BTW, nice work, David!

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