Well, I kinda gathered from your previously emails that we were kinda
getting out of your area of expertise, but you've still been quite
helpful. As I have searched throughout the jdbc drivers (they are not in a
jar), and they don't seem to have any libraries with them, I'll assume
they don't. I'
my understanding of the Sybase JDBC drivers is that they, like Oracle,
include native code. Thus somewhere out there on your dasd around about
the same place the jdbc drivers are (probably in a jar) there should be
a lib?.so. You may only be using classes, but they could have native
methods in
I'm sorry, but I'm obviously missing something. What *.so and *_g.so. As
far as I know the only libraries that I'm using are the ones included
with the JDK and Debug JDK Versions. I'm using class files for the Sybase
stuff. And my java files are not being compiled into a library. Maybe
I'm mi
On Sun, 17 Oct 1999, Chris Abbey wrote:
> 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/shar
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
13 matches
Mail list logo
