Weird Java 1.2 bug?
I'm having a problem with java 1.2 on a Redhat 5.2 system.
It seems that whenever I run any java application that 5 instances of that
program get loaded into memory. The same is true when I attempt to run
the rmiregistry. Is this normal? The same code that I'm running worked
perfectly on java 1.1.7. Any Ideas? Thanx in advance.
Trying to be happy is like trying to build a machine for which the only
specification is that it should run noiselessly.
Brandon Anderson
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RMI Troubles
I've got a little RMI Server setup on a Redhat 5.2 box that completely
quit working with java 1.2. Everything seems to startup on the server
side, but when I attempt to connect to it from a remote host I get the
following error:
Connection refused to host: [127.0.0.1:6299]; nested exception is:
java.net.ConnectException: Connection refused
I've tried running the client on java 1.1.7 and 1.2 but both yeild the
same error. I've changed the java.policy file to grant
java.security.AllPermissions to all the java code on the box. The server
worked fine running on 1.1.7 v3. Any suggestions on why I can no longer
connect? Thanx in advance.
Trying to be happy is like trying to build a machine for which the only
specification is that it should run noiselessly.
Brandon Anderson
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Segmentation Fault and 1024-bit reselotion?
I've been trying to get Java 1.2 pre v2 to run on my Redhat 5.2 box. I evidently have run into some problems that make no sense to me at all, and was wondering if anyone else had any suggestions. The application that I'm trying to get to run connects to another machine and then should show a simple login screen. It connect to the other machine just fine, but when it goes to display the login screen all I get is blackscreen with a menubar across the top. After about 15 sec of total cpu usage I get the following error message: Exception occurred during event dispatching: java.lang.InternalError: Unsupported 1024-bit depth at sun.awt.motif.X11Graphics.X11LockViewResources(Native Method) at sun.awt.motif.X11Graphics.lock(X11Graphics.java:797) at sun.java2d.loops.LockableRaster.lock(LockableRaster.java:163) at sun.java2d.loops.RasterOutputManager.convertFrom(RasterOutputManager.java:1414) at sun.java2d.loops.RasterOutputManager.performOpaqueBlit(RasterOutputManager.java:979) at sun.java2d.loops.RasterOutputManager.compositeSrcDst(RasterOutputManager.java:654) at sun.java2d.loops.RasterOutputManager.renderImage(RasterOutputManager.java:472) at sun.java2d.SunGraphics2D.renderingPipeImage(SunGraphics2D.java:2040) at sun.java2d.SunGraphics2D.drawImage(SunGraphics2D.java:1634) at sun.awt.motif.X11Graphics.drawImage(X11Graphics.java:583) at javax.swing.JComponent.paint(JComponent.java:536) at java.awt.Container.paint(Container.java:770) at javax.swing.JFrame.update(JFrame.java:255) at sun.awt.motif.MComponentPeer.handleEvent(MComponentPeer.java:248) at java.awt.Component.dispatchEventImpl(Component.java:2429) at java.awt.Container.dispatchEventImpl(Container.java:1032) at java.awt.Window.dispatchEventImpl(Window.java:714) at java.awt.Component.dispatchEvent(Component.java:2289) at java.awt.EventQueue.dispatchEvent(EventQueue.java:258) at java.awt.EventDispatchThread.run(EventDispatchThread.java:68) SIGSEGV 11* segmentation violation stackpointer=0x416f4e7c Full thread dump Classic VM (Linux_JDK_1.2_pre-release-v2, green threads): "AWT-Finalizer" (TID:0x404c55f8, sys_thread_t:0x8681d98, state:CW) prio=9 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:424) at sun.awt.AWTFinalizer.run(AWTFinalizer.java:46) The Full Thread dump continues on for several screens and I'll omit that from here. I'm using the Green Threads and the JIT is disabled. Any suggestions on what this problem is? Thanx in advance -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Segmentation Fault and 1024-bit reselotion?
Here is the results from xdpyinfo name of display:linuxBox.ccsoft.com:1.0 version number:11.0 vendor string:The Olivetti & Oracle Research Laboratory vendor release number:3323 maximum request size: 4194300 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:2 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 keycode range:minimum 8, maximum 255 focus: window 0x28e, revert to Parent number of extensions:7 BIG-REQUESTS MIT-SHM MIT-SUNDRY-NONSTANDARD SHAPE SYNC XC-MISC XTEST default screen number:0 number of screens:1 screen #0: dimensions:1024x768 pixels (260x195 millimeters) resolution:100x100 dots per inch depths (1):16 root window id:0x25 depth of root window:16 planes number of colormaps:minimum 1, maximum 1 default colormap:0x21 default number of colormap cells:64 preallocated pixels:black 0, white 65535 options:backing-store YES, save-unders YES largest cursor:1024x768 current input event mask:0x50003d KeyPressMask ButtonPressMask ButtonReleaseMask EnterWindowMask LeaveWindowMask SubstructureRedirectMask PropertyChangeMask number of visuals:1 default visual id: 0x22 visual: visual id:0x22 class:TrueColor depth:16 planes available colormap entries:64 per subfield red, green, blue masks:0x3f, 0x7c0, 0xf800 significant bits in color specification:8 bits As you can see, the depth is really only 16 bits. But one thing that might be important to mention is that I'm not actually running X. I'm running Xvnc. I've tried the same program on an actual X console(just a second ago), and it seems to work. Any ideas on how I can get this to work in Xvnc, or does it sound like I'm just going to be screwed? Oh by the way, on a side not, everytime I run any program that uses awt classes I get the following warning a whole bunch of time. It doesn't seem to cause any problems but its starting to get annoying. Font specified in font.properties not found [--zapf dingbats-medium-r-normal--*-%d-*-*-p-*-adobe-fontspecific] I'd prefer to fix without having to comment out the 20-30 lines in the font.properties, but if that's the only solution On Wed, 21 Jul 1999, Nathan Meyers wrote: > There are a lot of X server display depths and visuals that the AWT > doesn't support, because they don't happen to exist on Solaris boxes > :-(. But do you *really* have a 1024-bit deep display??? Could you post > the results of running xdpyinfo? This I gotta see :-). > > Nathan > > > Brandon Anderson wrote: > > > > I've been trying to get Java 1.2 pre v2 to run on my Redhat 5.2 box. I > > evidently have run into some problems that make no sense to me at all, and > > was wondering if anyone else had any suggestions. > > > > The application that I'm trying to get to run connects to another machine > > and then should show a simple login screen. It connect to the other > > machine just fine, but when it goes to display the login screen all I get > > is blackscreen with a menubar across the top. After about 15 sec of total > > cpu usage I get the following error message: > > > > Exception occurred during event dispatching: > > java.lang.InternalError: Unsupported 1024-bit depth > > > > at sun.awt.motif.X11Graphics.X11LockViewResources(Native Method) > > at sun.awt.motif.X11Graphics.lock(X11Graphics.java:797) > > at sun.java2d.loops.LockableRaster.lock(LockableRaster.java:163) > > at > > sun.java2d.loops.RasterOutputManager.convertFrom(RasterOutputManager.java:1414) > > at > > >sun.java2d.loops.RasterOutputManager.performOpaqueBlit(RasterOutputManager.java:979) > > at > > sun.java2d.loops.RasterOutputManager.compositeSrcDst(RasterOutputManager.java:654) > > at > > sun.java2d.loops.RasterOutputManager.renderImage(RasterOutputManager.java:472) > > at > > sun.java2d.SunGraphics2D.renderingPipeImage(SunGraphics2D.java:2040) > > at sun.java2d.SunGraphics2D.drawImage(SunGraphics2D.java:1634) > > at sun.awt.motif.X11Graphics.drawImage(X11Graphics.java:583) > > at javax.swing.JComponent.paint(JComponent.java:536) > > at java.awt.Container.paint(Container.java:770) > > at javax.swing.JFrame.update(JFrame.java:255) > > at > > sun.awt.motif.MComponentPeer.handleEvent(MComponentPeer.java:248) &g
Re: Problems installing JDK 1.1.7 and JDK 1.2 pre-v2
Actually, I believe the problem is related to the fact the NT doesn't support symbolic links. Almost all the files in the ($JAVA_HOME)/bin directory are symbolic links to .java_wrapper. The only two files that aren't symbolic links are .java_wrapper and java-rmi.cgi (atleast on 1.2). On Mon, 23 Aug 1999, Larry Gates wrote: > > >From: "Dimitris Terzis" <[EMAIL PROTECTED]> > >Date: Mon, 23 Aug 1999 14:53:03 +0100 > > >Hi guys... > > > >I have finally managed to install JDK1.1.7_v1a and JDK1.2... You won't > > >What happened is that, to download the tar files, I used an NT machine, > >linked to my Linux PC via Samba. So far so good. But, being lazy in typing > >"tar -xvf" under Linux, I used WinZip to un-tar and then copied the > >extracted files into the Linux JDK directory (1.1.7 or 1.2, respectively) > >directly. Well, I don't know why (please somebody explain), but with this > >procedure I kinda "lost" files during the WinZip extraction!!! The jdk/bin > > kinda? If they weren't really lost, but corrupted, I've had the same > "experience". If you don't set the "TAR LF to CR/LF Translation" to > off within WinZip, any ascii files within your tar-file will be > changed. The default is set to ON in WinZip (unfortunately). > > -Larry Gates > > > -- > 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]
Re: Unidentified subject!
Just in case you have discovered your error. You have an extra close bracket
before the statement your getting the error on. I've marked it in your code
below with a few ***. I'd suggest either doing your brackets in such a way
that they line up, or you learn to proofread your code just a little better.
On Tue, 24 Aug 1999, R MUTHUSWAMY wrote:
>
> hi,
> i have written a program to display a bulk of images in a one by one
> manner. but in the compilation it is showing a Type Expected error in the
> if(donecount == tracked) line.
> can anybody tell me the reason for the error. i got the same type of
> error in other program earlier which i couldn't solve. And also i heard
> that the same error is coming in the Windows also.
> Any explanation is appreciated.
>
>
>
> import java.util.*;
> import java.applet.*;
> import java.awt.*;
>
> public class TrackerImageLoad extends Applet implements Runnable {
>
> MediaTracker tracker;
> int tracked;
> int frame_rate = 5;
> int current_img =0;
> Thread motor;
> static final int MAXIMAGES = 10;
> Image img[] = new Image[MAXIMAGES];
> String name[] = new String[MAXIMAGES];
>
> public void init() {
> tracker = new MediaTracker(this);
> StringTokenizer st = new StringTokenizer(getParameter("img"), "+");
>
> while(st.hasMoreTokens() && tracked <= MAXIMAGES) {
> name[tracked] = st.nextToken();
> img[tracked] = getImage(getDocumentBase(), name[tracked]+".jpg");
> tracker.addImage(img[tracked], tracked);
> tracked++;
>
> }
> }
>
> public void paint(Graphics g) {
> String loaded = "";
> int donecount =0;
>
> for(int i=0; i if(tracked.checkID(i, true))
> donecount++;
> loaded += name[i] +"";
> }
> }
^ ** Here is your extra bracket
>
> Dimension d = getSize();
> int w = d.width;
> int h = d.height;
>
>
> if (donecount ==tracked) {
> frame_rate =1;
> Image i = img[current_img++];
>
> int iw= i.getWidth(null);
> int ih = i.getHeight(null);
> g.drawImage(i, (w - iw)/2, (h-ih)/2, null);
> if(current_img >=tracked)
> current_img =0;
> }
> else {
>int x = w * donecount / tracked;
>g.setColor(Color.black);
>g.fillRect(0, h/3, x, 16);
>g.setColor(Color.black);
>g.fillRect(x, h/3, w-x, 16);
>g.setColor(Color.black);
>g.drawString(loaded, 10, h/2);
>
> }
>
> }
>
> public void start() {
> motor = new Thread(this);
> motor.start();
>
> }
>
> public void stop() {
> motor.stop();
> }
>
> public void run() {
> motor.setPriority(Thread.MIN_PRIORITY);
> while(true) {
> repaint();
> try {
> Thread.sleep(1000/frame_rate);
>
> }
> catch(InterruptedException e ) {};
> }
> }
> }
>
>
>
> --
> 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]
Runtime.traceMethodCalls()
I've been trying to get the Runtime.traceMethodCalls() and the Runtime.traceInstructions working in Java under linux for quiet some time, and can't seem to figure out what I'm doing wrong. I'm starting to wonder if they are implemented at all in the Linux version, or if I have to do some special compile time switches... I'm actually calling the functions doing a Runtime.getRuntime().traceMethodCalls() and Runtime.getRuntime().traceInstructions() but I've tried with just straight Runtime.trace* and that doesn't seem to work either. Is it outputting it to a specific file somewhere that I'm just not finding, or is this really not implemented on the Linux version. The Java specs do say this is an optional thing for the JVM to do, but it would be an immensely useful debugging tool. Well, I was just wondering if I should waste any more time trying to get this to work under Linux. Thanx in advance. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Const in java
On Fri, 15 Oct 1999, Robert Simmons wrote: > > - Original Message - > From: Gordon Keith <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Cc: Robert Simmons <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Wednesday, October 13, 1999 8:36 PM > Subject: Re: Const in java > > > > [EMAIL PROTECTED] wrote: > > > > > > On Wed, 13 Oct 1999, Robert Simmons wrote: > > > > > > > Since everything in java is passed by reference this becomes even more > of an issue. > > > > Therefore can I do the following to achieve the desired safety ? > > > > > > Well, everything is not passed by reference in Java. I believe > primitives > > > and immutable types are passed by value. Someone know the exact rules > > > behind this? > > > > Everything is passed by value. > > But you never actually pass objects, you only ever pass references to > > objects. > > > > Making a parameter final means you can't change what object that > > parameter refers to. (you can still make changes to the object, if it's > > not immutable) > > Such is the problem there are times where I dont want the user to be able > to alter a returned object's state. > That's easy enough to get around. All you do is clone the object before you give it back to them. All java Objects should have a clone() function since that's part of the Object class. That is unless I'm misunderstanding what the clone() function does, which I wouldn't put past me. > > > > Once you understand that its pretty clear what's happening. > > > > Regards > > Gordon > > > > > > Gordon Keith > > Programmer > > Marine Science Support > > Australian Antarctic Divsion > > http://www.antdiv.gov.au > > > > > -- > 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]
Re: Runtime.traceMethodCalls()
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 > Brandon> linux for quiet some time, and can't seem to figure out > Brandon> what I'm doing wrong. > > Brandon> I'm starting to wonder if they are implemented at all in > Brandon> the Linux version, or if I have to do some special > Brandon> compile time switches... > > Brandon> I'm actually calling the functions doing a > Brandon> Runtime.getRuntime().traceMethodCalls() and > Brandon> Runtime.getRuntime().traceInstructions() but I've tried > Brandon> with just straight Runtime.trace* and that doesn't seem > Brandon> to work either. > > Brandon> Is it outputting it to a specific file somewhere that I'm > Brandon> just not finding, or is this really not implemented on > Brandon> the Linux version. The Java specs do say this is an > Brandon> optional thing for the JVM to do, but it would be an > Brandon> immensely useful debugging tool. > > Tracing only works with the debug version of java. Use 'java_g' > instead of 'java'. > > > Juergen > > > -- > Juergen Kreileder, Blackdown Java-Linux Porting Team > http://www.blackdown.org/java-linux.html > > > -- > 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]
java_g
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). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: java_g
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 would accept RMI connections. I'm running the rmiregistry_g and all the code that is currently being used has been compiled with javac_g, so I just don't get what's wrong. On Sat, 16 Oct 1999, 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 the jdk. Is it a development version or should it > >actually run correctly? > > The debug version of the JDK is specifically to help debug programs. > This also means that you need to have any RMI code built for debugging. > > -- > Michael Sinz Technology and Engineering Director/Consultant > "Starting Startups" mailto:[EMAIL PROTECTED] > My place on the web ---> http://www.users.fast.net/~michael_sinz > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: java_g
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, 16 Oct 1999, Brandon Anderson wrote: > 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 would accept RMI > connections. > > I'm running the rmiregistry_g and all the code that is currently being used has > been compiled with javac_g, so I just don't get what's wrong. > > On Sat, 16 Oct 1999, 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 the jdk. Is it a development version or should it > > >actually run correctly? > > > > The debug version of the JDK is specifically to help debug programs. > > This also means that you need to have any RMI code built for debugging. > > > > -- > > Michael Sinz Technology and Engineering Director/Consultant > > "Starting Startups" mailto:[EMAIL PROTECTED] > > My place on the web ---> http://www.users.fast.net/~michael_sinz > > > > > > > -- > 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]
Re: java_g
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 implemented according to the Java 1.2 API. I don't want to debug the program, but I do want to add the feature of being able to dynamically turn on the output of debugging information in such a way that it doesn't hurt performance. (i.e. Send an RMI message to the program and it automatigically starts to output what functions its executes). On Sat, 16 Oct 1999, Weiqi Gao wrote: > Brandon Anderson wrote: > > > > 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. > > On a logical level, javac_g is the debug version of javac. As a > consequence, javac_g works exactly the same as javac. Doing a "javac > Foo.java" and a "javac_g Foo.java" will produce exactly the same > output. Thus javac_g is useful to debug "javac the program" itself, > which application developers don't usually do. > > To compile your Java source into a debuggable version of class files, > use the -g switch, i.e., "java -g Foo.java". The resulting Foo.class > file can then be debugged with jdb. You can either run "java -debug > Foo" and then debug it over the network, or you can run "jdb Foo" to > debug it locally. > > Contrary to the situation with C programs, line numbers of source code > are always compiled into the class files, whether you use the -g switch > or not. It's the other stuff (local variable names, etc.) that's added > when you compile with the -g switch. > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: java_g
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
Full thread dump Classic VM (Linux_JDK_1.2_pre-release-v2, green threads):
"RMI ConnectionExpiration-[server.name.com:1099]" (TID:0x407d2548,
sys_thread_t:0x82a4398, state:CW) prio=5
at java.lang.Thread.sleep(Native Method)
at
sun.rmi.transport.tcp.TCPChannel$Reaper.run(TCPChannel.java:525)
at java.lang.Thread.run(Thread.java:479)
"RMI LeaseChecker" (TID:0x407d2460, sys_thread_t:0x82a0680, state:CW)
prio=5
at java.lang.Thread.sleep(Native Method)
at sun.rmi.transport.DGCImpl$LeaseChecker.run(DGCImpl.java:303)
at java.lang.Thread.run(Thread.java:479)
"RMI TCP Connection(2)-server.name.com/192.168.1.111"
(TID:0x407d0d18, sys_thread_t:0x828a780, state:CW) prio=5
at java.net.SocketInputStream.socketRead(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:90)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:190)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:229)
at java.io.BufferedInputStream.read(BufferedInputStream.java:285)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:190)
at java.io.BufferedInputStream.read(BufferedInputStream.java:208)
at java.io.DataInputStream.readByte(DataInputStream.java:224)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:428)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:607)
at java.lang.Thread.run(Thread.java:479)
"GC Daemon" (TID:0x407cd9e8, sys_thread_t:0x8243638, state:CW) prio=2
at java.lang.Object.wait(Native Method)
at sun.misc.GC$Daemon.run(GC.java:107)
"RMI Reaper" (TID:0x407cd818, sys_thread_t:0x8234fb0, state:CW) prio=5
at java.lang.Object.wait(Native Method)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:112)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127)
at sun.rmi.transport.ObjectTable$Reaper.run(ObjectTable.java:288)
at java.lang.Thread.run(Thread.java:479)
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 );
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?
On Sat, 16 Oct 1999, Chris Abbey wrote:
> 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 stack. The
> only thing you have to do special for working with _g is compile debuggable
> versions of *your* *native* *libs*. usually a quick `ln -s libmine.so
> libmine_g.so` is all it takes. -=Chris
>
>
> 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]
Re: java_g
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]
Re: java_g
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 missing your point, but please enlighten me. On Sun, 17 Oct 1999, Chris Abbey wrote: > At 12:46 10/17/99 -0600, Brandon Anderson wrote: > >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. > > you might try symlinking the *.so as *_g.so. Since that might not work, > you might follow up with an email to sybase's support folks or a sybase > specific ng or listserve, someone else may have already fought this... > > > 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]
Re: java_g
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'll look into getting the newer version of the JDBC drivers, which I want anyway, and see if that doesn't help. Thanx for your help. On Mon, 18 Oct 1999, Chris Abbey wrote: > 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 them - in fact they probably do. This is where someone from > the Sybase user community (or better yet, their support department) would > be very handy to have in on the discusion - they may very well say that > they don't have any, and that all IPC is handled by tcp sockets and high > level protocols... in which case the question to them is "then why does > getConnection() fail under only java_g??" (I'm assuming it works under > normal java) Note that when I started trying to help I understood the > problem to be with in RMI when trying to use Runtime.trace*() . . . my > code does that all the time, thus I was sure I could help you; now that > it's looking like Sybase I'm getting farther and farther out of my watter, > aside from basic JNI issues. -=Chris > > At 14:57 10/18/99 -0600, Brandon Anderson wrote: > >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 missing your point, but please enlighten me. > > > 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]
JComboBox and Focus/KeyListeners
I have been unable to get a JComboBox to report any Key/Focus Events to
listeners. I have checked the archives on the mailing list and the bug reports
and couldn't find the problem reported. I have encountered the problem in both
the Windows and Linux JVM's so I'm wondering at this point whether its my
problem or the JVM's problem. Can a JComboBox not have a Focus/Key
Listener? If not, Why not?
Anyway, here is a small sample code that demonstrates my problem.
When the JComboBox Gains/Loses Focus or has key pressed while its in focus you
should get a little message like:
Component 0 Lost Focus
Component 0 Gained Focus
Component 0 Key Pressed
Well, you get the idea.
---
import javax.swing.JFrame;
import javax.swing.JComboBox;
import javax.swing.JPanel;
import javax.swing.JTextField;
import java.awt.event.FocusListener;
import java.awt.event.FocusEvent;
import java.awt.event.KeyListener;
import java.awt.event.KeyEvent;
import java.awt.Component;
import java.awt.FlowLayout;
import java.util.Vector;
public class testClass extends JFrame implements FocusListener,
KeyListener
{
Vector
componentList = null;
public testClass()
{
JPanel panel = new JPanel(new FlowLayout());
componentList = new Vector();
componentList.addElement(new JComboBox());
componentList.addElement(new JTextField(10));
for (int i = 0; i < componentList.size(); i++)
{
((Component)componentList.elementAt(i)).addFocusListener(this);
((Component)componentList.elementAt(i)).addKeyListener(this);
panel.add((Component)componentList.elementAt(i));
}
this.getContentPane().add(panel);
setSize(320,200);
setVisible(true);
}
public void focusLost(FocusEvent e)
{
System.out.println("Component " +
componentList.indexOf(e.getSource()) + " Lost Focus");
}
public void focusGained(FocusEvent e)
{
System.out.println("Component " +
componentList.indexOf(e.getSource()) + " Gained Focus");
}
public void keyTyped(KeyEvent e)
{
System.out.println("Component " +
componentList.indexOf(e.getSource()) + " Key Typed");
}
public void keyPressed(KeyEvent e)
{
System.out.println("Component " +
componentList.indexOf(e.getSource()) + " Key Pressed");
}
public void keyReleased(KeyEvent e)
{
System.out.println("Component " +
componentList.indexOf(e.getSource()) + " Key Released");
}
public static void main(String args[])
{
testClass t = new testClass();
}
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
