Re: [Sablevm-developer] Runaway memory usage

[Archie C. <ar...@de...>]

Etienne M. Gagnon wrote:
> > I've upgraded Soot from 1.2.3 to 1.2.4 and now I'm having a problem
> > running it with SableVM (version 1.0.5).
> > 
> > The problem is that the sablevm process seems to eat up an infinite
> > amount of memory, bringing my machine to a grinding, thrashing halt.
> > 
> > I've tried to limit sablevm by adding this to my ~/.sablevm file:
> > 
> >     property = sablevm.heap.size.increment=0
> >     property = sablevm.heap.size.min=16777216
> >     property = sablevm.heap.size.max=16777216
> >     property = sablevm.classloader.heap.size.increment=0
> >     property = sablevm.classloader.heap.size.min=16777216
> >     property = sablevm.classloader.heap.size.max=16777216
> >...
> 
> That was a good idea.
> 
> Now, it seems we need to know which allocation site is causing these
> problems.  You might want to poke around using electric-fence (and/or
> other malloc debuggers) to try identifying the leaking site.

Here's some more info on this problem.

First of all, I was forgetting to limit the stack growth. So I added
these lines to ~/.sablevm:

    property = sablevm.stack.size.increment=4194304
    property = sablevm.stack.size.min=4194304
    property = sablevm.stack.size.max=33554432

However, setting 'sablevm.stack.size.max' doesn't actually do anthing...

You can verify this by reviewing the code for uses of 'vm->stack_max_size'.
This variable is never actually used, so no matter what the properties
are set to, there is no bound to the stack growth of any thread.

Aside from that, there is some other memory corruption bug.
Here is a GDB stack trace:

#4  0x2818bbdd in realloc () from /usr/lib/libc_r.so.4
#5  0x2806b2eb in _svmf_realloc (ptr=0xaca0000, size=180355072) at system.c:141
#6  0x28070ac8 in _svmf_ensure_stack_capacity (env=0x8061900, 
    frame_size=178286532) at thread.c:238
#7  0x280c65ad in _svmf_interpreter (_env=0x8061900)
    at instructions_preparation_direct_threaded.c:17986
#8  0x28079098 in _svmh_invoke_static_virtualmachine_runthread (env=0x8061900)
    at method_invoke.c:4941
#9  0x280710ff in _svmf_thread_start (_env=0x8061900) at thread.c:1028
#10 0x281197e3 in _thread_start () from /usr/lib/libc_r.so.4
#11 0x0 in ?? ()

Note the absurd 'frame_size=178286532' value being passed to
_svmf_ensure_stack_capacity() (because of the first bug, it actually
tries to allocate that much memory, but nevermind that for a minute)...
This value results from a corrupted 'method' structure. It appears
that the 'method->frame_info' pointer is bogus:

(gdb) frame 7
#7  0x280c65ad in _svmf_interpreter (_env=0x8061900)
    at instructions_preparation_direct_threaded.c:17986
17986               if (_svmf_ensure_stack_capacity
(gdb) list
17981
17982                   frame->stack_size = stack_size;
17983                   instance = stack[stack_size].reference;
17984                 }
17985
17986               if (_svmf_ensure_stack_capacity
17987                   (env, frame_info->java_invoke_frame_size) != JNI_OK)
17988                 {
17989                   goto exception_handler;
17990                 }
(gdb) p *frame
$14 = {previous_offset = 40, end_offset = 48, method = 0xaa07244, 
  stack_trace_element = 0x0, lock_count = 0, this = 0x90309d0, pc = 0xaa07d20, 
  stack_size = 0}
(gdb) p *method
$15 = {access_flags = 10, name = 0xaa06bc4, descriptor = 0xaa06c2c, 
  attributes_count = 0, attributes = 0x0, class_info = 0x8, 
  method_id = 178285632, synchronized = 0, java_args_count = 10, 
  parameters_gc_map = 0xaa06bc4, frame_info = 0xaa06c44, prepared_info = {
    code = 0x0, non_parameter_ref_locals_count = 0, start_offset = 10, 
    end_offset = 178285508, java_invoke_frame_size = 178285640, 
    internal_invoke_frame_size = 0}, non_prepared_info = {code = 0x0, 
    non_parameter_ref_locals_count = 8, start_offset = 178285644, 
    end_offset = 0, java_invoke_frame_size = 8, 
    internal_invoke_frame_size = 178285648}, reflection_instance = 0x0, 
  data = {code_attribute = 0xa, native_method = 0xa}}
(gdb) p *method->frame_info
$16 = {code = 0xaa06f78, non_parameter_ref_locals_count = 178286468, 
  start_offset = 178286480, end_offset = 178286516, 
  java_invoke_frame_size = 178286532, internal_invoke_frame_size = 178286544}
(gdb) x/64w 0xaa06c00
0xaa06c00:      0x0aa06de0      0x0aa06dfc      0x0aa06e10      0x0aa06e20
0xaa06c10:      0x0aa06e34      0x0aa06e50      0x0aa06e68      0x0aa06e84
0xaa06c20:      0x0aa06e9c      0x0aa06eb8      0x0aa06ed0      0x0aa06ef4
0xaa06c30:      0x0aa06f00      0x0aa06f0c      0x0aa06f18      0x0aa06f40
0xaa06c40:      0x0aa06f64      0x0aa06f78      0x0aa06f84      0x0aa06f90
0xaa06c50:      0x0aa06fb4      0x0aa06fc4      0x0aa06fd0      0x0aa06fe0
0xaa06c60:      0x0aa06fec      0x0aa06ff8      0x0aa0701c      0x0aa0703c
0xaa06c70:      0x0aa07058      0x0aa07074      0x0aa07090      0x0aa070a4
0xaa06c80:      0x0aa070e0      0x0aa0711c      0x0aa07134      0x0aa07154
0xaa06c90:      0x0aa0716c      0x0aa07190      0x0000000a      0x0aa06bf4
0xaa06ca0:      0x0aa06c2c      0x0a08afc4      0x00000000      0x0000000a
0xaa06cb0:      0x0aa06bf0      0x0aa06c30      0x0aa077e8      0x00000000
0xaa06cc0:      0x00000009      0x0aa06bf0      0x0aa06c34      0x00000000
0xaa06cd0:      0x00000000      0x00000007      0x0aa06c38      0x00000000
0xaa06ce0:      0x00000000      0x00000007      0x0aa06c3c      0x00000000
0xaa06cf0:      0x00000000      0x0000000a      0x0aa06bc4      0x0aa06c2c

I'll keep investigating and report any more info.

-Archie

__________________________________________________________________________
Archie Cobbs     *     Packet Design     *     http://www.packetdesign.com