Thread: [Sablevm-developer] Runaway memory usage
Brought to you by:
egagnon
Menu
▾
▴
sablevm-developer
|
From: Archie C. <ar...@de...> - 2002-12-13 01:15:04
|
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
Here's what happens:
$ sablevm --verbose-gc soot.Main -O --jimple Test
[verbose gc: allocating fixed size heap (2 * 16777216 bytes)]
Soot started on Fri Dec 13 00:53:14 GMT 2002
[verbose gc: previously allocated 16764392 bytes, surviving 4175580 bytes, new heap is 16777216 bytes, gc time = 0 sec 161959 usec]
[verbose gc: previously allocated 16767392 bytes, surviving 6926324 bytes, new heap is 16777216 bytes, gc time = 0 sec 252533 usec]
Transforming Test... ^C^C
At that point I killed sablevm because the system was going to
kill it anyway when it ran out of swap. The last top(1) snapshot
showed this:
last pid: 566; load averages: 0.33, 0.25, 0.19 up 0+00:34:11 16:54:00
70 processes: 1 running, 69 sleeping
CPU states: 3.1% user, 0.0% nice, 44.2% system, 0.8% interrupt, 51.9% idle
Mem: 103M Active, 952K Inact, 18M Wired, 312K Cache, 22M Buf, 492K Free
Swap: 133M Total, 60M Used, 73M Free, 45% Inuse, 248K Out
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
566 archie 28 0 179M 90108K pfault 0:25 46.27% 42.29% sablevm
...
Notice sablevm is using 179M of memory! Any ideas how to fix this?
And what is different about the new version of Soot that triggers this?
Thanks,
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
|
|
From: Etienne M. G. <eti...@uq...> - 2002-12-13 06:12:24
|
On Thu, Dec 12, 2002 at 05:02:24PM -0800, Archie Cobbs 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. http://metalab.unc.edu/pub/Linux/devel/lang/c/ElectricFence-2.0.5.tar.gz On Debian: $ apt-get install electric-fence $ LD_PRELOAD=libefence.so sablevm soot.Main -O --jimple Test and $ man efence Etienne -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Etienne M. G. <eti...@uq...> - 2002-12-13 06:18:15
|
On Fri, Dec 13, 2002 at 01:09:30AM -0500, Etienne M. Gagnon wrote: > 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. Ooops. libefence is probably not of much use for memory leaks. You might want to try memprof instead. http://people.redhat.com/~otaylor/memprof/index.html Etienne -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Archie C. <ar...@de...> - 2002-12-13 19:30:09
|
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
|
|
From: Archie C. <ar...@de...> - 2002-12-13 22:30:03
|
Archie Cobbs wrote: > 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: Further progress report on this... It appears that SableVM is trying to run the START_PREPARE_INVOKEVIRTUAL "bytecode" using a '_svmt_CONSTANT_Methodref_info' which describes an interface method instead of an instance method. The result is that the computed method_id is 616 which of course is supposed to be an interface method index but SableVM tries to use it as a virtual method index to the vtable, hence the 'corrupted method' and crash. The method being executed is soot.AbstractValueBox.setValue(). The interface method that this method is trying to invoke is soot.ValueBox.canContainValue(). So in summary, a concrete method (setValue()) in an abstract class (AbstractValueBox) that implements an interface (ValueBox) is trying to invoke an abstract interface method (canContainValue()) using the 'this' object. Hopefully this rings a bell.. ? I haven't been able to reproduce this with a simple example. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com |
|
From: Archie C. <ar...@de...> - 2002-12-14 01:15:07
|
Archie Cobbs wrote: > > 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: > > Further progress report on this... Now I've gotten this: $ sablevm Foo Test Transforming Test... assertion "_svmf_is_assignable_from (env, instance->vtable->type, _svmf_cast_type_class (method->class_info))" failed: file "instructions_preparation_direct_threaded.c", line 17953 Abort(core dumped) Wondering if this is a FreeBSD problem, I tried running on Linux: $ cat > .gdbinit file /usr/local/bin/sablevm-debug set args --verbose-gc soot.Main --jimple Test run break _svmf_error_OutOfMemoryError break _svmf_error_OutOfMemoryError_msg $ gdb GNU gdb 5.0rh-5 Red Hat Linux 7.1 Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux". No ssh-agent found. [New Thread 1024 (LWP 2869)] [verbose gc: allocating fixed size heap (2 * 16777216 bytes)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 2869)] 0x400351e2 in _svmf_invoke_native_nonstatic (env=0x804e2a0) at native.c:1293 1293 params[0].reference = *obj; Breakpoint 1 at 0x4001e622: file error_throwing.c, line 2501. Breakpoint 2 at 0x4001e75a: file error_throwing.c, line 2566. (gdb) c Continuing. Cannot find user-level thread for LWP 2869: generic error (gdb) c Continuing. Cannot find thread 1024: generic error $ sablevm-debug --verbose-gc soot.Main --jimple Test [verbose gc: allocating fixed size heap (2 * 16777216 bytes)] Segmentation fault $ uname -a Linux foobar5.packetdesign.com 2.4.18 #4 SMP Mon Oct 7 09:52:52 PDT 2002 i686 unknown Note: this is a 2-CPU machine. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X