Re: Crash in garbage collector

Re: Crash in garbage collector

[Jan Hoogerbrugge]

>Jan Hoogerbrugge wrote:
>>I encounter segmentation faults in my port when the garbage collector 
>>becomes
>>active, so I am in trouble. Can somebody give me hints on how I can debug 
>>this
>>and what could be wrong.
>
>There is a --enable-checking=gcac configure option that will force a 
>garbage collect on every entry into the gc routines.  This will usually 
>force an error shortly after the mistake, making it easier to find the 
>mistake.  There are also other checking options that might be useful. See 
>the docs and the ggc code.

Thanks.

The --enable-checking=gcac option did not trigger the problem. After that
I figured out that there are two garbage collectors: page and zone. When
I configure gcc for zone the crashes disappear. Also, then I define
COOKIE_CHECKING in ggc-zome.c, I see no crashes. Any idea why I have
crashes with page and not with zone (I tested this on a large number of
files)? If not, I will keep on using zone.

Jan

_________________________________________________________________
Hotmail en Messenger on the move 
http://www.msn.nl/communicatie/smsdiensten/hotmailsmsv2/

Re: Crash in garbage collector

[Daniel Berlin]

On Apr 20, 2004, at 9:40 AM, Jan Hoogerbrugge wrote:

>> Jan Hoogerbrugge wrote:
>>> I encounter segmentation faults in my port when the garbage 
>>> collector becomes
>>> active, so I am in trouble. Can somebody give me hints on how I can 
>>> debug this
>>> and what could be wrong.
>>
>> There is a --enable-checking=gcac configure option that will force a 
>> garbage collect on every entry into the gc routines.  This will 
>> usually force an error shortly after the mistake, making it easier to 
>> find the mistake.  There are also other checking options that might 
>> be useful. See the docs and the ggc code.
>
> Thanks.
>
> The --enable-checking=gcac option did not trigger the problem. After 
> that
> I figured out that there are two garbage collectors: page and zone. 
> When
> I configure gcc for zone the crashes disappear. Also, then I define
> COOKIE_CHECKING in ggc-zome.c, I see no crashes.
>  Any idea why I have
> crashes with page and not with zone (I tested this on a large number of
> files)?

They are completely different in almost every way, so no.
> If not, I will keep on using zone.
>
Zone has some know problems in relation with ggc_free that i just 
haven't gotten to fixing yet, so watch out.

--Dan

Crash in garbage collector

[Jan Hoogerbrugge]

Hi,

I encounter segmentation faults in my port when the garbage collector 
becomes
active, so I am in trouble. Can somebody give me hints on how I can debug 
this
and what could be wrong. I already figured out that I had to add GTY(()) 
annotations
and some things to mark roots for garbage collection. However after I did 
that
the crash is still there.

Jan



Program received signal SIGSEGV, Segmentation fault.
0x08328033 in lookup_page_table_entry (p=0x8555fb0) at ggc-page.c:588
588       return base[L1][L2];
(gdb) bt
#0  0x08328033 in lookup_page_table_entry (p=0x8555fb0) at ggc-page.c:588
#1  0x0832635a in ggc_set_mark (p=0x8555fb0) at ggc-page.c:1258
#2  0x080e6918 in gt_ggc_ma_alias_invariant (x_p=0x8555fb0) at 
gt-alias.h:413
#3  0x081ff8f2 in ggc_mark_roots () at ggc-common.c:115
#4  0x083272f5 in ggc_collect () at ggc-page.c:1995
#5  0x08378575 in cse_main (f=0x4064eee0, nregs=1273, after_loop=1, 
file=0x0)
    at cse.c:7009
#6  0x0832a77b in rest_of_handle_cse2 (decl=0x401a0ca8, insns=0x4064eee0)
    at passes.c:1329
#7  0x0832b4e1 in rest_of_compilation (decl=0x401a0ca8) at passes.c:1797
#8  0x08339354 in tree_rest_of_compilation (fndecl=0x401a0ca8, 
nested_p=false)
    at tree-optimize.c:202
#9  0x0807a54c in c_expand_body_1 (fndecl=0x401a0ca8, nested_p=0)
    at c-decl.c:6284
#10 0x0807a821 in c_expand_body (fndecl=0x401a0ca8) at c-decl.c:6316
#11 0x0833cbad in cgraph_expand_function (node=0x4022c654) at 
cgraphunit.c:791
#12 0x0833e8e0 in cgraph_expand_all_functions () at cgraphunit.c:1573
#13 0x0833ebc8 in cgraph_optimize () at cgraphunit.c:1663
#14 0x080d9dfe in c_objc_common_finish_file () at c-objc-common.c:241
#15 0x08055613 in finish_file () at c-lang.c:202
#16 0x080cb19c in c_common_parse_file (set_yydebug=0) at c-opts.c:1239
#17 0x082e44d5 in compile_file () at toplev.c:1595
#18 0x082e5df2 in do_compile () at toplev.c:2629
#19 0x082e5e52 in toplev_main (argc=20, argv=0xbfffd674) at toplev.c:2661
#20 0x080dd5f2 in main (argc=20, argv=0xbfffd674) at main.c:35
#21 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6
(gdb)

_________________________________________________________________
Play online games with your friends with MSN Messenger 
http://messenger.msn.nl/

Re: Crash in garbage collector

[Geoff Keating]

"Jan Hoogerbrugge" <hoogerbrugge@hotmail.com> writes:

> Hi,
> 
> I encounter segmentation faults in my port when the garbage collector
> becomes
> active, so I am in trouble. Can somebody give me hints on how I can
> debug this
> and what could be wrong. I already figured out that I had to add
> GTY(()) annotations
> and some things to mark roots for garbage collection. However after I
> did that
> the crash is still there.

Perhaps you didn't allocate an 'alias_invariant' structure using ggc_alloc?

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Crash in garbage collector

[Jim Wilson]

Jan Hoogerbrugge wrote:
> I encounter segmentation faults in my port when the garbage collector 
> becomes
> active, so I am in trouble. Can somebody give me hints on how I can 
> debug this
> and what could be wrong.

There is a --enable-checking=gcac configure option that will force a 
garbage collect on every entry into the gc routines.  This will usually 
force an error shortly after the mistake, making it easier to find the 
mistake.  There are also other checking options that might be useful. 
See the docs and the ggc code.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Crash in garbage collector

[Jon Beniston]

Hi all,

I have been working on a port of GCC to a new architecture, which for
the most part is compiling reasonably well. However, for a few files, I
am seeing crashes in the garbage collector. The first time I had this
problem, it disappeared when I changed:

label = gen_rtx (LABEL_REF, VOIDmode, operands[0]);

To 

label = gen_rtx_LABEL_REF (VOIDmode, operands[0]);

in one of my machine specific source files. Can anyone explain how this
might have effected things? Unfortunatly, this didn't fix all of the
crashes I was seeing, and I have no more calls to gen_rtx. I have tried
configuring with --enable-checking, but this hasn't shed any light on
the subject so far. 

What are the typical porting errors that can cause this kind of failure
(if there is such a thing)?

Incidentally, this happens on both Linux and Cygwin. My port is based on
the gcc-3.3.2 release.

Cheers,
JonB

Re: Crash in garbage collector

[Geoff Keating]

"Jon Beniston" <jbeniston@compxs.com> writes:

> Hi all,
> 
> I have been working on a port of GCC to a new architecture, which for
> the most part is compiling reasonably well. However, for a few files, I
> am seeing crashes in the garbage collector. The first time I had this
> problem, it disappeared when I changed:
> 
> label = gen_rtx (LABEL_REF, VOIDmode, operands[0]);
> 
> To 
> 
> label = gen_rtx_LABEL_REF (VOIDmode, operands[0]);
> 
> in one of my machine specific source files. Can anyone explain how this
> might have effected things? Unfortunatly, this didn't fix all of the
> crashes I was seeing, and I have no more calls to gen_rtx. I have tried
> configuring with --enable-checking, but this hasn't shed any light on
> the subject so far. 
> 
> What are the typical porting errors that can cause this kind of failure
> (if there is such a thing)?

This usually means that you have (a) a missing GC root, or (b) some
random memory overwrite problem that just happens to be noticed or
triggered or somehow affected by GC.

I recommend using GDB on the compiler and debugging the problem.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Crash in garbage collector

[Richard Sandiford]

"Jon Beniston" <jbeniston@compxs.com> writes:
> I have been working on a port of GCC to a new architecture, which for
> the most part is compiling reasonably well. However, for a few files, I
> am seeing crashes in the garbage collector. The first time I had this
> problem, it disappeared when I changed:
> 
> label = gen_rtx (LABEL_REF, VOIDmode, operands[0]);
> 
> To 
> 
> label = gen_rtx_LABEL_REF (VOIDmode, operands[0]);
> 
> in one of my machine specific source files. Can anyone explain how this
> might have effected things?
> [...]
> Incidentally, this happens on both Linux and Cygwin. My port is based on
> the gcc-3.3.2 release.

In the 3.3 series, gen_rtx() left '0'-type fields uninitialised.
Since the definition of LABEL_REF is:

    /* Reference to an assembler label in the code for this function.
       The operand is a CODE_LABEL found in the insn chain.
       The unprinted fields 1 and 2 are used in flow.c for the
       LABEL_NEXTREF and CONTAINING_INSN.  */
    DEF_RTL_EXPR(LABEL_REF, "label_ref", "u00", 'o')

this means that gen_rtx (LABEL_REF, ...) would only initialise the
first operand, not the other two.  Unfortunately, I think all three
operands are garbage collected, see gengtype.c:adjust_field_rtx_def().
So you'd end up collecting random addresses.

gen_rtx_LABEL_REF() sets the other two operands to null, so there's no
problem if you use that.

FWIW, the 3.4 version of gen_rtx() will initialise '0' fields to null.

Richard

RE: Crash in garbage collector

[Jon Beniston]

> "Jon Beniston" <jbeniston@compxs.com> writes:
> > I have been working on a port of GCC to a new architecture, 
> which for 
> > the most part is compiling reasonably well. However, for a 
> few files, 
> > I am seeing crashes in the garbage collector. The first time I had 
> > this problem, it disappeared when I changed:
> > 
> > label = gen_rtx (LABEL_REF, VOIDmode, operands[0]);
> > 
> > To
> > 
> > label = gen_rtx_LABEL_REF (VOIDmode, operands[0]);
> > 
> 
> In the 3.3 series, gen_rtx() left '0'-type fields 
> uninitialised. [..]
> gen_rtx_LABEL_REF() sets the other two operands to null, so 
> there's no problem if you use that.

Maybe the MIPS port needs patching then, because that's were I copied it
from.

The other crash I was seeing turned out to be a Cygwin-only problem.
Just for reference, it seemed to disappear by setting:

ac_cv_header_alloca_h=no ac_cv_func_mmap_dev_zero=no
ac_cv_func_mmap_anon=no ac_cv_func_mmap_file=no ac_cv_func_munmap=no
ac_cv_func_alloca_works=goats 

for configure. The goats value was used because it fails if you set yes
or no ;)

Cheers,
JonB