At 23:21 10/16/99 -0600, Brandon Anderson wrote:
>
>OK, here is the thread dump, but like I already wrote in the previous
>post I only get this while running java_g so I don't know if its really
>relevant.
>
>*** panic: "../../../../src/share/javavm/runtime/classresolver.c", line
>1285: assertion
At 22:57 10/16/99 -0600, Brandon Anderson wrote:
>If that's the case than why does my program run correctly when I compile
>it and run it with javac/java but not when I compile it with
untill you send us a stack trace and some actual concrete info about
what you're doing and running, no one can a
OK, here is the thread dump, but like I already wrote in the previous
post I only get this while running java_g so I don't know if its really
relevant.
*** panic: "../../../../src/share/javavm/runtime/classresolver.c", line
1285: assertion failure
SIGABRT 6* abort (generated by abort(3) rou
If that's the case than why does my program run correctly when I compile
it and run it with javac/java but not when I compile it with
javac_g/java_g? And how do I get Runtime.trace*() to work. I just simply
want to know if those function work under the Linux JVM. They are not
required to be imp
Overkill my friend... overkill. the _g versions don't change how they interact
with the outside world, only how they work internally. Class files generated
from javac and javac_g are the same. Unless you're debugging a failure of
rmiregistry there is no need for rmiregistry_g. Please send the stac
OK, so I found out that not all the code is compiled with javac_g. Is
there any way to get around having to compile all the code with javac_g.
I'm connecting to a database via some jdbc drivers and they are not
compiled with javac_g and I don't/can't have the source to them.
Any ideas?
On Sat,
At 19:47 10/16/99 -0400, Michael Sinz wrote:
>On Sat, 16 Oct 1999 15:47:02 -0600 (MDT), Brandon Anderson wrote:
>
>>Well, I tried to run my project with java_g as suggested. Unfortunately
now I
>>get a horrible RMI related thread dump. I was just wondering what
exactly is
>>the debug version of
I did recompile everything using javac_g, but that is when I get the nasty RMI
thread dump. I would assume that the other code connecting through RMI doesn't
have to be recompiled using the java_g. But that is pretty much irrelevant
since I can't even get this program get to the point where it w
On Sat, 16 Oct 1999 15:47:02 -0600 (MDT), Brandon Anderson wrote:
>Well, I tried to run my project with java_g as suggested. Unfortunately now I
>get a horrible RMI related thread dump. I was just wondering what exactly is
>the debug version of the jdk. Is it a development version or should it
Well, I tried to run my project with java_g as suggested. Unfortunately now I
get a horrible RMI related thread dump. I was just wondering what exactly is
the debug version of the jdk. Is it a development version or should it
actually run correctly?
Thanx again (in advance).
--
Thanx (to everyone),
That's an easier solution than I was hoping for.
On 16 Oct 1999, Juergen Kreileder wrote:
> > Brandon Anderson writes:
>
> Brandon> I've been trying to get the Runtime.traceMethodCalls()
> Brandon> and the Runtime.traceInstructions working in Java under
> B
Raja Vallee-Rai <[EMAIL PROTECTED]> wrote:
> We have formally evaluated the different virtual machines available for
> Linux and thought it would be worthwhile to share the results with
> the Linux community.
Thanks. The results are so interesting.
> ibmjit: speedup of the AlphaWorks IBM 1.1.8
> Brandon Anderson writes:
Brandon> I've been trying to get the Runtime.traceMethodCalls()
Brandon> and the Runtime.traceInstructions working in Java under
Brandon> linux for quiet some time, and can't seem to figure out
Brandon> what I'm doing wrong.
Brandon> I'm startin
13 matches
Mail list logo
