This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: hints on debugging memory corruption...

On Thu, 10 Feb 2011 15:32:39 +0100
Dodji Seketeli <> wrote:

> Joern Rennecke <> writes:
> > Quoting Tom Tromey <>:
> >
> >>>>>>> "Basile" == Basile Starynkevitch <> writes:
> >>
> >> Basile> So I need to understand who is writing the 0x101 in that field.
> >
> >
> >> One thing to watch out for is that the memory can be recycled.  I've
> >> been very confused whenever I've forgotten this.  I have a hack for the
> >> GC (appended -- ancient enough that it probably won't apply) that makes
> >> it easy to notice when an object you are interested in is collected.
> >> IIRC I apply this before the first run, call ggc_watch_object for the
> >> thing I am interested in, and then see in what GC cycle the real one is
> >> allocated.
> >
> > If what you are looking for survives such a change, postponing garbage
> > collection so it won't happen till the crash can make things simpler.
> For the sake of archiving these tricks how do you postpone garbage
> collection in practise?

BTW, postponing garbage collection is completely inpossible for me (at
the most, I could disable it in the gdb debugger, but not in real MELT
runs), since the GC (I mean the ggc_collect() routine) is called at
arbitrary moments by the MELT runtime (it is called from the MELT
garbage collector, routine melt_garbcoll(), which takes the appropriate
measures -together with the MELT translator- to do that safely.)

Thanks for all the help. I did find out what was wrong: it was my
(incorrect) understanding of get_loop_body. I thought (incorrectly)
that it returned a GTY-ed pointer.

In my opinion, that function has a bizarre property: it returns a
calloc-ed array of basic_block-s, which are themselves GTY-ed (that is
managed by the Ggc collector with the help of GTY annotations for

What I find bizarre, is that get_loop_body returns a manually managed
memory data chunk (an array, actually) of Ggc-ed pointers (as every one
guess, I do like the idea of a garbage collector, and my insane wish is
that GCC would have much more GTY-ed data. I do know that this mine
position is against the majority). I would find much more logical (or
at least more elegant to my eyes) if get_loop_body returned (for
instance) a GTY-ed vector [or any other GTY ((variable)) thing] of
loop-s pointers. Strangely, it doesn't!

In MELT parlance, I cannot simply make a MELT primitive which invokes
get_loop_body. It has to be interfaced by a MELT function which builds
a MELT tuple of MELT boxed basic_block-s. Now, this function needs
support from the MELT runtime to permit mutation of MELT boxed
basic_block-s. So I had to generate the meltgc_basicblock_updatebox in
file gcc/meltrunsup.h [that file is MELT generated. MELT is now able to
generate all the boxing, upboxing, hashmapping... of any GTY-ed
ctypes]. So I had to improve the MELT generator (file
melt/warmelt-outobj.melt) to do that generation of updatebox routines.
Once the generated code was better, I could commit it (using git) to
the MELT branch.

Now, I have to merge the latest trunk into the MELT branch, but since I
switched to git, I am very scared to do that, and I am not sure to
understand the reliable procedure to do so. (I was able to merge once
the trunk into MELT using git, but that was with the kind help of
Andreas Schwab and Dodji Seketeli, and I am not sure to have understood

Some of my uses of git (on GCC & MELT) gives me bizarre (hence scary)
messages. I am really ashamed to be a git newbie. I am sort of able to
use it on some (own, non GCC) code, but I am very scared of messing GCC
with git and I use it on GCC MELT with fear.

email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]