Possible bug in Thread.stop()?
Hello,
I'm using Blackdown's JDK 1.1.6 on Linux 2.0.34 (Redhat).
I'm having strange thread behaviour which (a) might
somehow be a bug in my code, but I doubt it
(b) might be a generic
Java problem, and not due to the Blackdown port
(c) might already be identified and fixed in 1.1.7.
If it is any of the above categories, I apologize.
I have an applet, which starts off on a main thread in
init(), and at some point in its lifecycle spawns off
a new thread in a Runnable object. Later on, the main
thread invokes stop() on the child thread. Roughly
80% of the time, this works correctly - the child thread
dies like it's supposed to. But about 20% of the time,
the child thread never dies. In fact, it never enters the
finalize() method I inserted to 'trap' this problem.
Here's some relevant snippets:
public class jppp extends Applet{
Thread counter = null;
public void init() {
//... bunch of init stuff...
counter = new Thread(new waitConnect());
counter.start();
}
// ... later on, in some event handling code .
log ("DEBUG " + Thread.currentThread() +
": Stopping the counter thread "+ counter);
counter.stop();
//
// waitConnect is a nested class within the applet
public class waitConnect implements Runnable{
protected void finalize() throws Throwable
{
log ("DEBUG " + Thread.currentThread() +
"In finalizer of waitConnect class");
}
public void run() {
// once a new thread starts executing in run, it enters
// a while(true) loop so lives forever until killed externally
while (true)
{
//...
if( //test a condition which means this thread should
// be gone, yet it's still alive)
{
log ("DEBUG " + Thread.currentThread() +
"Uh oh. In while(true) loop, but should be dead");
}
//
Thread.sleep(1000); //execute main loop every second
} // end while(true)
} // end run()
} // end of waitConnect (nested class)
} // end of jppp (applet)
The length of time between the thread.start() and stop()
can vary between a few seconds, to as long as 5 or 6 hours.
Most of the time, the logs I get look like this:
...
[10-Dec-98 2:50:08 AM jppp] : DEBUG Thread[AWT-EventQueue-0,5,main]:
Stopping the counter thread Thread[Thread-9,5,main]
[10-Dec-98 2:50:08 AM jppp] : DEBUG Thread[Finalizer thread,1,system]In
finalizer of waitConnect class
...
I.e., we see the log of the parent thread stopping the child,
and the log of the child in the finalizer as it is shut down.
However, occassionally (and usually on runs where the child
has been alive for several hours), the log is:
[10-Dec-98 12:56:09 PM jppp] : DEBUG Thread[AWT-EventQueue-0,5,main]:
Stopping the counter thread Thread[Thread-15,5,main]
[10-Dec-98 12:56:09 PM jppp] : DEBUG Thread[Thread-15,5,main] Uh oh. In
while(true) loop, but should be dead
[10-Dec-98 12:56:10 PM jppp] : DEBUG Thread[Thread-15,5,main] Uh oh. In
while(true) loop, but should be dead
[10-Dec-98 12:56:11 PM jppp] : DEBUG Thread[Thread-15,5,main] Uh oh. In
while(true) loop, but should be dead
[10-Dec-98 12:56:12 PM jppp] : DEBUG Thread[Thread-15,5,main] Uh oh. In
while(true) loop, but should be dead
I.e. , the parent has issued the same stop() as previously,
only the Finalizer in the child never got invoked,
and the child thread stays alive.
As I say, I suspect a bug in the implementation of stop().
Any ideas? Obviously, I can work around this problem by having
my child commit suicide in its 'if' detection. But I'm posting
this, since there may be a more general problem here of wider
interest.
Regards,
Ron
--
Ron Resnick
DiaLogos Incorporated
http://www.dialogosweb.com
Re: Java 1.2
Michael Privat wrote: > > Hi, > I realise you probably get this question ten thousand times a day, > but is there a Java v1.2 porting project ? Is there any approximation > about when it would be available ? > > Thanks a lot, > Michael Privat > > --- > Michael Privat > Massachusetts Institute of Technology > CECI - Advanced Artificial Intelligence - ALIVE Project > --- Hello, I've only been monitoring this list for a short while myself, but... this question does get asked a lot, and (I think) for good reason. One of the key reasons I started poking around on blackdown.org was to find out what the plans were for JDK1.2 on Linux. The FAQ is vague, and clearly was written some time ago. My main comment here is: I think it would be a good idea to update the FAQ, and perhaps also put a note on the blackdown.org Java-port main page, indicating the present status of 1.2 portation. Even if the only status that can be reported is "don't bug us! we're working on it and will let you know when we have something to tell you", that would be fine, presuming it was clear that this was datestamped after the official Sun release of Java2 a few days ago, so people knew it was recent info. Just my .02 Ron -- Ron Resnick DiaLogos Incorporated http://www.dialogosweb.com
Re: Java-VisiBroker CORBA on Linux with Blackdown Java 1.16/1.17 Howto
Armen Yampolsky wrote: > > Marcel, > > Thanks for your great summary! BTW, I just wanted to let you know, we've switched to >omniORB2/Sun IDL (JDK1.2) instead of Visibroker. I felt that visi was just way too > expensive, and being a believer in the benefits of Open Source software (and reading >all the great posts re omniORB), I decided to give it a try. The Sun java libs are > just enough for the client, definitely not good enough for a server, IMO, but we're >running a C++ appserver and so this fits beautifully. The two work together quite > well, and I only have good things to say about omniORB, so if you have similar >requirements, you may want to look into it. I guess this is sounding a bit like a >pitch ;) > > Naturally, all work splendidly on linux (with the exception of the absence of >idltojava compiler, which the Blackdown team should have up Real Soon Now, right?). > > Cheers, > -A. a. My thanks to Marcel as well - that was very helpful & timely Marcel, as I'm just now porting a Visibroker based CORBA training class from NT to Linux. Thanks! b. Armen, as I understand things, - omniORB2 is a C++ ORB (no Java lang. mappings at present). Presumably this is your "C++ appserver" correct? (And presumably you have this running on Linux?) - JavaIDL, as you note, requires JDK1.2, which as of now (this week/day, anyway :) still isn't avail. on Linux, so this is probably running for you on NT/Solaris/other, right? Hence, you have an environment using muliple lang (C++/Java), multiple platform (Linux server/ non-Linux client), multiple ORB (omniORB/JavaIDL). That's actually pretty impressive - if you have more operational stats (eg types of applications you are using this for, scaling you're getting, etc.) I'd be quite interested. However, just to be clear, the config. above at no point has the combination of "+Java +CORBA +Linux", right? I.e, the Java ORB is not on Linux, only the C++ ORB. I ask only because for those of us looking for an open source Java ORB on Linux, your config. above still doesn't quite fit. Or have I misunderstood you? Thanks, Ron -- Ron Resnick Senior Consulting Engineer DiaLogos Incorporated http://www.dialogosweb.com
Re: Java2
Jim Waldo - SMI Software Development wrote: > > Hi folks -- > > Any words on when the Java 2 (aka 1.2) port is available? I would love to get > a port of Jini out on Linux early (and often), but we are completely 1.2 > based. > > Any words you could give would be a help. > > Thanks, > > Jim Waldo Hi Jim, Your question (when is Blackdown JDK1.2 coming out) gets asked about 3 times a day on the Blackdown list :). For most folks who ask this, the standard answer is some combination of: (i) read the faq (ii) wait and bear it in silence (iii) #$@!!#$ In your case though, perhaps we could synergistically act to expedite things? I think it's great that senior folks within Sun, such as yourself, are interested in moving Java/Linux along. Recently, a member of the Blackdown team (Steve Byrne) informed us all that: > We're not legally allowed to put out pre-release versions if they haven't > passed through JCK. We're in the process of trying to chase down some issues > with running the JCK. > > > The page also says, "Before we can release, we have to make sure that it > > passes the tests in the Java Compatibility Kit." Is this a requirement > > of Sun's source code licensing, or is it just something that was decided > > on by the Blackdown team? > > It's the dreaded sections 2.4 and 2.5 as amending 2.3 of our license that say > we HAVE to pass JCK before we can release or even pre-release. > > Steve Certainly there are good reasons for ensuring that Java ports are "sanitized" by passing JCK. However, maybe there's a way that Sun can expedite this process for the Blackdown folks, or at least allow a controlled prerelease that lightens the impact of these "dreaded sections"? Do you think you could lend a hand here Jim? Or is this (probably) in the hands of some "dreaded lawyers" 8-). On another note, what do you mean by: "get a port of Jini out on Linux early (and often)"? I thought Jini was pure Java, i.e., as soon as there is a compliant JDK2 running on platform of choice, Jini is just a drop in, like JFC, JSDK, or any other pure Java package. Or is there native code in Jini that needs to be ported platform by platform? Thanks, Ron --- Ron Resnick Senior Consulting Engineer DiaLogos Incorporated http://www.dialogosweb.com
Re: Java-VisiBroker CORBA on Linux with Blackdown Java 1.16/1.17 Howto
Here's just a minor update to the excellent "HOWTO" Marcel Ruff forwarded last week on running VisiBroker for Java, on Linux: Marcel Ruff wrote: > > Hi, > after some mails about VisiBroker, here are some hints how to run > VisiBroker on Linux: > > 1) Everything from VisiBroker runs fine on Linux (pure Java), but not > the osagent process > which is nativ binary (and not supported on Linux) Not only is it native binary, but it's a windows (as opposed to dos) app. I tried to run osagent under dosemu on linux, hoping to avoid needing a dangling windows box on the network just for this purpose. Unfortunately, I get the standard 'must run this app under windows' message :-(. Bizarre, too, since osagent does fire up a window, but never does anything with it. Why they couldn't keep it as a background task, executable from a dos shell, is beyond me. (Though that's hardly the only example of poor Visibroker design). I've never run wine - any thoughts on whether it's worth trying to get osagent running on wine, or would I be wasting my time barking up this tree? Otherwise, everything worked just fine. My CORBA apps (I've now ported over about 4 from NT) run very smoothly over Blackdown (1.1.7v1a on x86). Ron
Re: Modal Dialog blocking sub-Windows
Carl H. Sayres wrote: > > We have a lightweight component which creates a secondary Window > as part of it's operation. This works fine in general on Linux > (and anywhere else as well). The problem occurs when this component > is used in a modal dialog. On Linux, the Modal dialog blocks any > input to the contents of the Window. > > This problem does not exist on win32. (I'm not certain if the > bug is in the Linux JDK and this should work, or in the win32 > JDK and this should not work! ;-) ) > > Any suggestions? > > - Carl Um, that's what modality means - that events don't reach the underlying window. As you describe it, it would seem that the Linux behaviour is correct. Then again, I've got modal apps that I've run on Windows too, and they work correctly. Keep in mind that there are 2 variants - you can use JOptionPane.showMessageDialog (or ConfirmDialog, or whatever), or you can use JOptionPane.showInternalMessageDialog . Which of these are you using? If you're seeing "funny stuff", my guess is you're using the latter, and my suggestion would be to use the former. The former works best, and would be my recommendation for most conceivable modal apps. The latter, in my experience, don't handle repainting properly and are best avoided unless you have a real application need for a modal InternalFrame. Anyway, as to your perceived Linux/Win behaviour difference, that sounds pretty odd (I hesitate to say implausable, but that's what I'm thinking..) since Swing lightweight components are pure Java, and use exactly the same drawing support regardless of platform. There's nothing in the Linux vs. Windows JDK that should have any effect on Swing behaviour. Ron
javac compiler exception
Heh.
You don't get to see internal javac compiler errors every day -
this was kind of neat:
[resnick@rresnick f3]$ javac foo.java
java.lang.NullPointerException
at
sun.tools.tree.ConditionalExpression.costInline(ConditionalExpression.java)
at
sun.tools.tree.BinaryExpression.costInline(BinaryExpression.java)
at
sun.tools.tree.ExpressionStatement.costInline(ExpressionStatement.java)
at sun.tools.java.FieldDefinition.cleanup(FieldDefinition.java)
at sun.tools.java.ClassDefinition.cleanup(ClassDefinition.java)
at sun.tools.javac.Main.compile(Main.java)
at sun.tools.javac.Main.main(Main.java)
error: An exception has occurred in the compiler; please file a bug
report (http://java.sun.com/cgi-bin/bugreport.cgi).
1 error
[resnick@rresnick f3]$
I'm posting this to blackdown, rather than reporting it to Sun,
since I'm not really sure it is a Sun javac problem, and I thought
the Java/Linux folks might want to see it first.
If it turns out not to be Linux
related, my apologies in advance for bringing it up here.
I encountered this using blackdown jdk117_v1a - maybe someone can
try this on a non-linux JDK to see if it is reproducible elsewhere?
I've not tried Jikes, though I'm sure it will compile cleanly with
Jikes.
I've isolated the reproducible problem down to one snippet .java file.
The error dump above came from:
//File foo.java
public class foo
{
public void bar(Object param)
{
if (Object.class == param.getClass()) {// do something}
}
}
As you can see, the problem involves reflection in a conditional
statement.
Note that my use
of 'Object' as the type of bar's parameter is arbitrary - any type
whatsoever for 'param' will produce this problem. The problem
appears to happen when a comparison is made in a conditional if
statement
between the reflected class of a method parameter (param.getClass())
and an expected class type ( someObject.class).
Here are some other interesting variants to the above:
//Variant a - still generates the internal compiler error
public class foo
{
public void bar(Object param)
{
// flip around the order of the == comparison arguments
if (param.getClass() == Object.class) {}
}
}
//Variant b - still generates the internal compiler error
public class foo
{
public void bar(Object param)
{
// try a different comparison operator -- !=
if (param.getClass() != Object.class) {}
}
}
//Variant c - compiles cleanly!
public class foo
{
public void bar(Object p)
{
Object param = p;
// replace the method parameter with an on-stack variable:
if (param.getClass() != Object.class) {}
}
}
Anyone else ever encountered this sort of thing?
Regards,
Ron.
---
Ron Resnick
Senior Consulting Engineer
DiaLogos Incorporated
http://www.dialogosweb.com
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
javac compiler exception - errata
Thanks for the rapid responses Martin, Steve. I'll quickly take this
off blackdown due to its non-Linux relevance. I thought I would point
out the following though:
If you insert an actual executable hunk of code into the if block,
things work properly. Eg, consider
class foo
{
void bar (Object o)
{
if (o.getClass() == Object.class)
{
Integer p // = new Integer(5)
;
}
}
}
As written, this generates the internal compiler error, since the simple
allocation
of reference p doesn't require runtime execution. However, uncomment the
initializer ( = new Integer(5)), and the internal compiler error
disappears.
The act of invoking new() seems to force the compiler to follow a
clean path, as opposed to a dirty one.
Looking at this, my guess is that the problem is caused by some
optimization
dealing with parameters on the stack. When the optimization is forcibly
turned
off, the problem goes away.
OK, I'll stop annoying you all. I guess I was just intrigued think about
what kind of internal optimization path could possibly account for these
unlikely stimuli turning on or off the behaviour.
Ron
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Off topic question..
Nathan Meyers wrote: > > Justin Knotzke wrote: > > > > Hi, > > > > I see that IBM is porting Websphere to Linux. Are they going to use > > your VM? If not, do you think they are going to port their VM to Linux? > > A look at their site doesn't suggest the existence of a "their VM", > other than a port of Sun's code to their platforms. Unless they want to > duplicate Blackdown's efforts, I can't imagine that they'd want to do > their own port to Linux. > > Nathan > Umm, this is not quite true. Yes, IBM is a licensor of Sun's code. Yes, their other platforms are "ports" of Sun VMs. However, IBM has spent a very large amount of effort in customizing, adapting and tuning Sun VMs to the 390, the AS/400 and the RS6000 environments. They're interested in making IBM servers the "servers of choice" for scalable server-oriented Java efforts. Having spent some time with people working on AS/400 and 390 VM groups within IBM, I can tell you there's a lot more going on than just trying to recompile Sun's code onto these targets. In particular, they've spent a lot of effort on garbage collection and mem.mgmt in the VMs. Now, none of that has any bearing on the original question of course, ie - would they use blackdown as their point of departure for Linux-based Java efforts. My own guess, like Nathan's, is that they would. After all, why on earth not?? It is the "official" Linux JDK. (What is the status of the Open Group Java/Linux effort? Is that still going on?) BTW - similar comments apply to Oracle. They've embedded a VM, again based on Sun code, into O8i. They're now releasing O8i onto Linux. My guess is that they would do some kind of merge of their own efforts with blackdown. [Hey - 3 cheers for the Java 2 SDK release :). Thanks Steve and others. ] Ron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Something Special for Linux Developers on alphaWorks
Paolo Ciccone wrote: > > > "OPD" == Osvaldo Pinali Doederlein <[EMAIL PROTECTED]> writes: > > OPD> That's great! I did see the announcements but I though the > OPD> code was still in the distant future, as I didn't see a > OPD> public splash of it. So, is 'vi' doomed now on Linux? :) > > Well, we just didn't to talk about vaporware even though JB has been > tested on Linux for some time. Also we were waiting for a more stable > JVM, JBuilder is one heavy application. As we said we are working on a > multiplatform version that will be released for Solaris *and* Linux. > As many of us know Java is "write once test everywhere" and there are > indeed differences in the way it works between Solaris and > Linux. > > --Paolo You wouldn't happen to know if JBuilder on Linux might also mean an imminent release of Oracle JDeveloper on Linux, which is itself heavily based on JBuilder? (And no, vi will never be toasted by IDEs - just look at the popularity of vim/bash on Windows, the land of IDEs.) Ron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
