This is the mail archive of the gcc-patches@gcc.gnu.org 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]

GC issues in cc1plus


Hi,
My previous patch ("Unify name lokkup 1/n") seems to have exposed a
latent GC issue in cc1plus.

  In cc1plus, we used to use a free list of "cxx_binding"s (a data
structure we allocate for nearly every declaration) that we recycle
for all local and class-scope bindings.  

Starting with my previous patch -- which fatorized the logic into
cxx_binding_make() -- one can notice more memory usage in cc1plus.
If one does -not- recycle the free bindings, then the memory usage
seems to be kept low, otherwise it gets higher.  
This looks like a GC issue to me.  I'm proposing, temporarily, the
following patch (which suppresses recycling).

Bootstrapped and tested on an i686-pc-linux-gnu.

I would like to thank Gerald would first noticed this problem on an
FreeBSD and offered me an access to that box to investigate the
problem and also actively  assisted me while investigating, and Roger
who just reported a similar thing with the following backtrace:

    cxx_binding_make (value=0x23be2a0, type=0x0)
        at ../../gcc/gcc/cp/name-lookup.c:42
    42            free_bindings = binding->previous;
    (gdb) print binding
    $1 = (cxx_binding *) 0xa5a5a5a5
    (gdb) where
    #0  cxx_binding_make (value=0x23be2a0, type=0x0)
        at ../../gcc/gcc/cp/name-lookup.c:42
    #1  0x00414281 in push_binding (id=0x22f1690, decl=0x23be2a0,
    level=0x1747070)
        at ../../gcc/gcc/cp/decl.c:893
    #2  0x0041488e in push_class_binding (id=0x22f1690, decl=0x23be2a0)
        at ../../gcc/gcc/cp/decl.c:1072
    #3  0x00420a65 in push_class_level_binding (name=0x22f1690, x=0x23be2a0)
        at ../../gcc/gcc/cp/decl.c:4264
    #4  0x004206a6 in pushdecl_class_level (x=0x23be2a0)
        at ../../gcc/gcc/cp/decl.c:4151
    #5  0x004ffade in setup_class_bindings (name=0x22f1690, type_binding_p=1)
        at ../../gcc/gcc/cp/search.c:2043
    #6  0x004ffc50 in dfs_push_type_decls (binfo=0x2379c80, data=0x0)
        at ../../gcc/gcc/cp/search.c:2090
    #7  0x004fdc68 in dfs_walk_real (binfo=0x2379c80, prefn=0,
        postfn=0x4ffbb0 <dfs_push_type_decls>,
        qfn=0x4ff400 <unmarked_pushdecls_p>, data=0x0)
        at ../../gcc/gcc/cp/search.c:1601
    #8  0x004fddae in dfs_walk (binfo=0x2379c80,
        fn=0x4ffbb0 <dfs_push_type_decls>, qfn=0x4ff400
    <unmarked_pushdecls_p>,
        data=0x0) at ../../gcc/gcc/cp/search.c:1615
    #9  0x005000c4 in push_class_decls (type=0x23a9b60)
        at ../../gcc/gcc/cp/search.c:2155

on a cygwin.

As a final datapoint, I would like to mention that this sort of
problem is difficult to track:  For example, running cc1plus under
GDB-5.3, I was unable to reproduce the problem; running cc1plus with no
optimization yields no failure; running g++ with optimization
reproduces the problem. 

Thanks,

-- Gaby
2003-03-31  Gabriel Dos Reis  <gdr at integrable-solutions dot net>

	* name-lookup.c (cxx_binding_make): Don't recycle free bindings.

Index: name-lookup.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/name-lookup.c,v
retrieving revision 1.2
diff -p -r1.2 name-lookup.c
*** name-lookup.c	30 Mar 2003 16:00:39 -0000	1.2
--- name-lookup.c	31 Mar 2003 04:04:17 -0000
*************** static GTY((deletable (""))) cxx_binding
*** 35,48 ****
  cxx_binding *
  cxx_binding_make (tree value, tree type)
  {
!   cxx_binding *binding;
!   if (free_bindings)
!     {
!       binding = free_bindings;
!       free_bindings = binding->previous;
!     }
!   else
!     binding = ggc_alloc (sizeof (cxx_binding));
  
    binding->value = value;
    binding->type = type;
--- 35,41 ----
  cxx_binding *
  cxx_binding_make (tree value, tree type)
  {
!   cxx_binding *binding = ggc_alloc (sizeof (cxx_binding));
  
    binding->value = value;
    binding->type = type;


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