[Bug libgcj/26063] New: memory leak in _Jv_Linker::link_symbol_table

[Bug libgcj/26063] New: memory leak in _Jv_Linker::link_symbol_table

[thebohemian at gmx dot net]

My patch for PR 24616 introduced a memory leak in _Jv_Linker::link_symbol_table
because some ffi structures and a String are not reachable by the garbage
collector.

It was decided to accept this problem because the above mentioned patch got
bigger and bigger.


-- 
           Summary: memory leak in _Jv_Linker::link_symbol_table
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgcj
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: thebohemian at gmx dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26063

[Bug libgcj/26063] memory leak in _Jv_Linker::link_symbol_table

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-02-01 14:43 -------
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-02-01 14:43:40
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26063

[Bug libgcj/26063] memory leak in _Jv_Linker::link_symbol_table

[thebohemian at gmx dot net]

------- Comment #2 from thebohemian at gmx dot net  2006-02-01 16:52 -------
Added aph to get some ideas on how to solve this.

Some ideas:
The code that uses the ffi structure is so complicated because it is neccessary
to prepare a call that takes one argument (a class name). I plan to put setup
code into a separate method because I saw another location where this behavior
is needed (link.cc around line 1203).

Furthermore I was told that the ffi functions are not implemented on certain
architectures (eg ARM) and would cause compilation problems.

The new method would take this into account and provide a path with degraded
functionality: Do not create any ffi stuff and do not provide the name of the
missing class as argument.

I am a bit clueless on how to solve the memory leak thing and appreciate ideas
& pointers.


-- 

thebohemian at gmx dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aph at redhat dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26063

[Bug libgcj/26063] memory leak in _Jv_Linker::link_symbol_table

[aph at gcc dot gnu dot org]

------- Comment #3 from aph at gcc dot gnu dot org  2006-02-01 16:57 -------
Working around the lack of libffi support on ARM is Just Plain Stupid.  We
should either fix it or cease to build on ARM.  Without libffi libgcj cannot
work in any reasonable way.

The memory leak thing can be fixed by using RawDataManaged, but it's not worth
worrying about ATM.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26063

[Bug libgcj/26063] memory leak in _Jv_Linker::link_symbol_table

[tromey at gcc dot gnu dot org]

------- Comment #4 from tromey at gcc dot gnu dot org  2006-02-01 18:32 -------
FWIW, some embedded users want to be able to remove ffi --
not for its own sake but because they also want to remove
the interpreter, reflection info (see David Daney's recent
proposal).  It doesn't seem that hard to have a #if and avoid
making a closure if libffi is not available.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26063

[Bug libgcj/26063] memory leak in _Jv_Linker::link_symbol_table

[thebohemian at gmx dot net]

------- Comment #5 from thebohemian at gmx dot net  2006-02-02 12:06 -------
The ffi usage breaks the build on arm :(

Can someone tell me which macro I can use to test ffi availability?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26063

[Bug libgcj/26063] memory leak in _Jv_Linker::link_symbol_table

[aph at gcc dot gnu dot org]

------- Comment #6 from aph at gcc dot gnu dot org  2006-02-02 12:10 -------
See java/lang/reflect/natMethod.cc:

#if USE_LIBFFI
#include <ffi.h>
#else
#include <java/lang/UnsupportedOperationException.h>
#endif


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26063

[Bug libgcj/26063] memory leak in _Jv_Linker::link_symbol_table & ffi usage breaks build on ARM

[thebohemian at gmx dot net]

------- Comment #7 from thebohemian at gmx dot net  2006-02-02 12:52 -------
Changed the title and have a preliminary patch.


-- 

thebohemian at gmx dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |thebohemian at gmx dot net
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2006-02-01 14:43:40         |2006-02-02 12:52:37
               date|                            |
            Summary|memory leak in              |memory leak in
                   |_Jv_Linker::link_symbol_tabl|_Jv_Linker::link_symbol_tabl
                   |e                           |e & ffi usage breaks build
                   |                            |on ARM


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26063

[Bug libgcj/26063] memory leak in _Jv_Linker::link_symbol_table & ffi usage breaks build on ARM

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2006-02-02 12:56 -------
PR 26073 is the PR for ffi usage that breaks ARM.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |26073


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26063

[Bug libgcj/26063] memory leak in _Jv_Linker::link_symbol_table & ffi usage breaks build on ARM

[thebohemian at gmx dot net]

------- Comment #8 from thebohemian at gmx dot net  2006-02-02 12:56 -------
Created an attachment (id=10771)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10771&action=view)
a preliminary patch (not tested)

Unfortunately I am in a hurry and have to leave soon. If anyone depends on the
ARM compilation problem being fixed immediately then this patch will be the
start.

Complains, hints, remarks and so on are appreciated. :)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26063

[Bug libgcj/26063] memory leak in _Jv_Linker::link_symbol_table & ffi usage breaks build on ARM

[thebohemian at gmx dot net]

------- Comment #10 from thebohemian at gmx dot net  2006-02-02 19:26 -------
(From update of attachment 10771)
Forget about this patch. it doesnt compile and there is a working one on the
java-patches list.


-- 

thebohemian at gmx dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #10771|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26063

[Bug libgcj/26063] memory leak in _Jv_Linker::link_symbol_table

[tromey at gcc dot gnu dot org]

------- Comment #11 from tromey at gcc dot gnu dot org  2006-02-04 02:50 -------
The simplest way to solve the memory leak is to make a new structure
which holds all the data, then allocate an instance of this.
This structure can be allocated with _Jv_AllocBytes, I believe, as the
atable ought to be scanned by the collector (currently anyway).

I have a patch to do this.

In the future, just file a new PR when there is a new bug.  Reusing
an existing bug is somewhat weird.


-- 

tromey at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|thebohemian at gmx dot net  |tromey at gcc dot gnu dot
                   |                            |org
            Summary|memory leak in              |memory leak in
                   |_Jv_Linker::link_symbol_tabl|_Jv_Linker::link_symbol_tabl
                   |e & ffi usage breaks build  |e
                   |on ARM                      |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26063

[Bug libgcj/26063] memory leak in _Jv_Linker::link_symbol_table

[tromey at gcc dot gnu dot org]

------- Comment #12 from tromey at gcc dot gnu dot org  2006-02-08 20:07 -------
Subject: Bug 26063

Author: tromey
Date: Wed Feb  8 20:07:29 2006
New Revision: 110763

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110763
Log:
        PR libgcj/26063, PR libgcj/17978, PR libgcj/10598:
        * defineclass.cc (parse): Use _Jv_AllocRawObj.
        (read_constpool): Likewise.
        (read_one_code_attribute): Use internal function name.
        (handleConstantPool): Use _Jv_AllocRawObj.
        (handleInterfacesBegin): Likewise.
        (handleFieldsBegin): Likewise.
        (handleMethodsBegin): Likewise.
        (handleCodeAttribute): Likewise.
        (handleMethodsEnd): Likewise.
        * include/jvm.h (new_vtable): Use _Jv_AllocRawObj.
        * interpret.cc (do_allocate_static_fields): Use _Jv_AllocRawObj.
        Allocate reference fields separately.
        * link.cc (prepare_constant_time_tables): Use _Jv_AllocRawObj.
        (add_miranda_methods): Likewise.
        (generate_itable): Use _Jv_AllocBytes.
        (find_iindex): Likewise.
        (struct method_closure): New structure.
        (create_error_method): Use struct method_closure; allocate with
        _Jv_AllocBytes.
        (ensure_fields_laid_out): Separate reference fields from
        non-reference fields.
        * boehm.cc (_Jv_MarkObj): Mark vtable.  Only mark direct fields
        of Class.
        (_Jv_MarkArray): Mark vtable.
        (_Jv_AllocRawObj): Don't allocate objects of size 0.
        * include/execution.h
        (_Jv_ExecutionEngine::allocate_static_fields): Added 'int'
        parameter.
        (struct _Jv_CompiledEngine): Updated.
        (class _Jv_InterpreterEngine): Updated.

Modified:
    trunk/libjava/ChangeLog
    trunk/libjava/boehm.cc
    trunk/libjava/defineclass.cc
    trunk/libjava/include/execution.h
    trunk/libjava/include/jvm.h
    trunk/libjava/interpret.cc
    trunk/libjava/link.cc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26063

[Bug libgcj/26063] memory leak in _Jv_Linker::link_symbol_table

[tromey at gcc dot gnu dot org]

------- Comment #13 from tromey at gcc dot gnu dot org  2006-02-08 20:10 -------
Fix checked in.


-- 

tromey at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.2.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26063