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/share/javavm/runtime/classresolver.c", line
> >1285: assertion failure
> >
> >SIGABRT 6* abort (generated by abort(3) routine)
> > stackpointer=0xbfffe370
> >
>
> ahh... now I understand better.... based on your previous statement:
> "I get the nasty RMI thread dump." I was assuming that you took an
> RMI related exception. (RMI is one of my fields, I was hoping it was
> something I could help with.)
>
> >
> >This continues for quite a while - atleast 2-3 pages worth of garbage. It
> >happens as soon as I try to connect to the database. This is the code
> >that it executes immediately before.
> >
> >
> > Class.forName("com.sybase.jdbc.SybDriver").newInstance();
> > String cInfo = "jdbc:sybase:Tds:server.name.com:20001";
> >
> > Connection dbConn = DriverManager.getConnection( cInfo, _props );
Sorry I meant to indicate that it dies on the very last line on the
DriverManager.getConnection( ...) statement. I think your probably right
that it is because the sybase drivers don't have debugging information
built into them, or some similar situation. Is there any way to get
around this? I don't care to actually have the sybase
instructions/functions printed. So if there is a possible way to exclude
these from being including in the debugging (Yeah, I know I'm dreaming), I
would be happy to try it.
Oh by the way, as a side question, does anyone know where I can get the
latest version of the Sybase Drivers. I'm still using jdbc 1.0 drivers
and the newer ones are suppose to have a few extra features (like batch()
commands) that would come in handy.
>
> one of those threads in that stack should be the one going through this
> code (I don't see it in the part you provided). See if you can find it and
> see what it's doing. I suspect it is on the Class.forName() call which is
> causing the class loader to blow up because sybase doesn't include
> debuggable drivers (or so I'm told . . . anyone from Sybase listening?)
> We have a similar problem at work with Oracle only providing dlls for Sun's
> VM and not IBM's. Another possibility would be that the Sybase classes load
> a native so and call a method in their static initializer that causes an
> abort signal... but I don't think this is how the classloader would respond
> to that case.
>
> >But again, this may all be unnecessary since the only thing I want to do
> >is have a working version of Runtime.trace*() functions. They don't seem
> >to do anything normally, or I just don't know how to use them properly?
>
> I suspect you do. Try this trivial test class out... if it works then you'll
> prove to your self you've got your environment setup and that you know what
> you're doing.
>
> public class test {
> public static void main(String[] args) {
>
> System.out.println("running");
>
> Runtime.getRuntime().traceMethodCalls(true);
> System.out.println("trace
> this call");
> Runtime.getRuntime().traceMethodCalls(false);
>
> System.out.println("done");
> }
> }
>
> or try using the -tm command line arg with your favorite hello world.
>
> cabbey at home dot net <*> http://members.home.net/cabbey
> I want a binary interface to the brain!
> Today's opto-mechanical digital interfaces are just too slow!
>
>
> ----------------------------------------------------------------------
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
