[kaffe] bug report: core dump after eating cpu (gc related?)
auto97841 at hushmail.com
Fri Nov 21 06:06:02 PST 2003
Oh, its certainly a memory leak, I said the *application* isn't leaking
ram, as when I spent a few days w/ JProfiler profiling its memory and
CPU usage on a completely different OS and JVM (xp, sun 1.4.2), it used
a steady 2-3Mb (in addition to ~8-12 from the jvm), as opposed to on
freebsd/kaffe where it starts with 17Mb and grows to 64Mb until it dumps
core. Are there any known leaks in the jvm or javalib that I can check
my usage against?
I don't mean to sound like "my code is perfect, the jvm is broken" -
it may be some way I'm using objects that sun's gc deals with them in
a different way than kaffe's. but whenever a jvm crashes and dumps core
- and they all do sometimes - there's a problem in the jvm. hostile
classes should be able to consume ram and cpu, but never dump core.
(not that my code is hostile)
Anyway, two questions -
* in the gc/memory management code, there are certainly very good reasons
to use __assert, but I only see a few references in mem/gc-incremental.c
to OutOfMemoryError. are there some of these asserts that could make
sense as OOMs?
* does kaffe have a signal or some other mechanism that I can use to
get a thread dump of a currently running application? I don't have a
/proc/ to gcore & gdb with - I was thinking something along the lines
of kill -QUIT / ^BREAK with sun's jvms?
On Fri, 21 Nov 2003 03:08:03 -0800 "Kevin D. Kissell" <kevink at mips.com>
>Sure looks and sounds like a memory leak to me...
Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2
Free, ultra-private instant messaging with Hush Messenger
Promote security and make money with the Hushmail Affiliate Program:
More information about the kaffe