Re: bug report: core dump after eating cpu (gc related?)

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?

tia,
-jr

On Fri, 21 Nov 2003 03:08:03 -0800 "Kevin D. Kissell" <kevink@xxxxxxxx>
wrote:
>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
https://www.hushmail.com/services.php?subloc=messenger&l=434

Promote security and make money with the Hushmail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427