 |
Author |
Topic: Applet freezing problem: any clues? (Read 978 times) |
|
ed
 
|
Applet freezing problem: any clues?
« on: Oct 1st, 2003, 9:59am » |
|
My advance apologies for a very unfocused problem here. I've a P5 project that's prone to suddenly and inexplicably freeze while running [both in Sun & Microsoft VM as far as I can tell]. I can detect no correlation between interaction/rendering events and freezing [it will happily freeze spontaneosly even if I leave it running without interaction for several minutes]. By freezing I mean all animation/interaction ceases, however the frozen image survives intact when obscured/revealed by other windows, so it wouldn't appear to be a total death of the applet. Naturally I've had my java console up with maximum debug feedback but I get not so much as a sniff of an exception. I've hunted for possible infinite loops I could be falling into, but besides not finding any the fact that the CPU usage drops from 90% to 0 the instant it freezes would seem to suggest that it's not an infinite loop of mine.
So, hey ho, I thought I'd share my problem incase it's a processing problem that other folks know and love already. Some manner of thread deadlocking would seem a likely culprit? It might be that my frames are very computationally expensive as they're doing lots and lots of comparisons between byte arrays to simulate springy collisions between convex polygons. Could this be causing some kind of deadlock between the rendering and event threads [which I was suprised to discover appear to be independant of each other in processing, that's an race condition accident waiting to happen that is!] I've had the problem from versions 58 through 65 (was keeping quiet in the hope that it would cure itself with the next release!). The problematic program in question is at...
http://www.soda.co.uk/moovl/
It's a program that adds very naive physics to drawings in realtime. Even if there's no solution on offer you might enjoy playing with Moovl until it freezes anyway! Have some fun drawing poeple and things and bouncing them into each other [I was particularly suprised to discover that you draw a bottle and fill it with drops of ink, hoorah- collision-detection-tastic!].
Sorry to ramble, I'm all debugged out on this one!
cheers,
Ed.
|
|
|
|
|
elout
 
|
Re: Applet freezing problem: any clues?
« Reply #1 on: Oct 1st, 2003, 10:33am » |
|
I played with it for 7+ minutes and no freezing.. can you give a specific time, when this freezing thing happens on your machine?
|
|
|
|
|
ed
|
Re: Applet freezing problem: any clues?
« Reply #2 on: Oct 1st, 2003, 11:16am » |
|
on Oct 1st, 2003, 10:33am, elout wrote:I played with it for 7+ minutes and no freezing.. can you give a specific time, when this freezing thing happens on your machine
|
|
well I guess that's good news! Alas I've as yet failed to indentify a pattern to the freezing; sometimes it will run merrily for 10 minutes or more, other times it will freeze within a minute or so. With symtoms like that I'd suspect a memory leak [well, as close as one can get in java], but I don't see any evidence of memory being consumed over time when I use the task manager or use the java console to dump memory usage intermitantly. grrrumph.
|
|
|
|
|
arielm
|
Re: Applet freezing problem: any clues?
« Reply #3 on: Oct 1st, 2003, 12:48pm » |
|
very nice stuff!
played with it a bit, but couldn't get it stuck...
something that could help to identify the source of the problem (i.e. bagel or java):
with a version prior to 060, you could try to include in your code something like: Code:void keyPressed()
{
System.out.println("foo");
}
|
|
prior to 060, this code should be executed in another thread, so, supposing that you're stuck in the main applet's thread, this one should still be alive and send something to the java console...
if it's not working, it's likely that it's a java problem, i guess...
(but if it does work, then it will definitely be possible to go further and isolate the problem!)
hth
|
Ariel Malka | www.chronotext.org
|
|
|
fry
|
Re: Applet freezing problem: any clues?
« Reply #4 on: Oct 1st, 2003, 1:33pm » |
|
are you using a dual processor machine where you're seeing the freezes?
|
|
|
|
|
ed
|
Re: Applet freezing problem: any clues?
« Reply #5 on: Oct 2nd, 2003, 10:05am » |
|
on Oct 1st, 2003, 1:33pm, fry wrote:| are you using a dual processor machine where you're seeing the freezes |
|
humm, not unless the test computers have got another processor that they've been keeping secret from me. In the olden days of programming in c++ Id've had a debugger to hand to suspend excecution and step into the code; any top tips on tools/techniques to monitor what the java VM is doing more closely I can't remember the last time the Codewarrior debugger worked for java  .
|
|
|
|
|
ed
|
errors in event threads? what's going on up there?
« Reply #6 on: Oct 5th, 2003, 6:42pm » |
|
so, I'm still banging my head against this darn freezing bug. My current hunch is that I might have been thrown off the scent by some error handling behaviour that I don't understand in P5. Here's a booby trapped program to try and isolate my confusion...
Code:void setup()
{
}
void loop()
{
}
void mousePressed() {
println("entering mousePressed");
String s=null;
println("I'm going to throw a NullPointerException if I try to reference "+s.length());
println("exiting mousePressed");
}
void mouseMoved() {
println("entering mouseMoved");
String s=null;
println("I'm going to throw a NullPointerException if I try to reference "+s.length());
println("exiting mouseMoved");
} |
|
If you run it in the P5 [I'm in rev 65 these days] environment upon moving the mouse over the applet one will see "entering mouseMoved" followed by the expected NullPointer Exception splurging out onto the console. After that exception has been thrown mouse movement has no further effect. However for mouse presses you see "entering mousePressed" followed by the exception every time you press the mouse, not just the first time. I don't undersand why an exception in mouseMoved prevents all subsequent mouseMoved's whereas mousePressed survives to throw another error each time.
What strikes me as even stranger and a possible cause of my woes is that when the sketch is exported and run in a browser [IE+Sun VM 1.4.2_01] I get the same behaviour for the mouse presses ["entering mousePressed" followed by the beloved NullPointerException]. However for the mouse move I only get "entering mouseMoved" echoed once to the console, and no evidence of the NullPointerException apart from the fact that mouseMoved doesn't work from then on.
So now I'm wondering if my program is just throwing some exception or other in a place where this strange absense of error feedback applies? What's going on with event threads and is there some error trapping that's stopping normal exception throwing and reporting above my code in the BApplet? Is mouseMoved a special case in this respect or is it more widespread? Am I imagining all this?
Yours, dribbling in debugging delirium, Ed.
|
|
|
|
|
fry
|
Re: Applet freezing problem: any clues?
« Reply #7 on: Oct 6th, 2003, 5:54pm » |
|
there's a bug with recent releases of the environment that a runtime exception, like the NullPointerException can cause a lockup of the environment, though i don't think it'll affect exported applets. for instance, the code:
int a = 5/0;
will compile, but freeze the environment (watch out!) this is something that will be fixed in 66 (this week). i don't think this affects exported applets though, so that shouldn't affect your situation (except to throw you off the scent by giving you the lockup when doing a println with that 'null' String).
mousePressed/mouseMoved may also be bad for debugging, since they're tied to the applet thread, and are queued to only be called at the end of loop() (as of rev 60, iirc). if you overload "public void mousePressed(MouseEvent e)" you can get better (asynchronous) results, if those are needed. but be sure to call "super.mousePressed(e);" at the beginning so that mouseX and mouseY properly update (though this will also call the other mousePressed() with no args.. fyi).
as for printing things that are null.. that seems to be a problem with newer JVMs. i've seen it mostly in 1.4 and higher, where printing a null object to the console (in any java app, not restricted to p5) will cause things to lock up. not sure what the problem is there, but it seems to be a jvm annoyance.
regarding your problem with only the "entering.." line showing up (not the line with the null string prined) in the browser, i'm guessing that's weirdness with the i/o. the exception, and the buffering involved with println() will be somewhat inconsistent. that is, the NullPointerException will happen, but the flush() on the OutputStream used by the console may or may not happen prior to things actually locking up, so you might not get to see the additional line of text. ah, it's lovely, no? part of the beauty of that comes from the fact that the java console for the plugin is itself written in java, compounding the inconsistency. the genius of it all!
so in the end, the things you cite are all independent problems, but i'm guessing that none of them are your root problem with your applet. unless, of course, you're doing a println() on something that's null, which would do that lockup.
as for other methods to debug.. if you run your applet as an application (see threads elsewhere on the board) you can interrupt the app using ctrl-\ or something like that (a google check should turn up the proper sequence) to get a dump of the threads that are running, and their current state, so you can see if it's a deadlock. i haven't had *lots* of lock with this method, but it's there. actually, maybe you can even do this inside p5, though you'll hose things prolly.
i wonder if borland's optimizeit would have a way to debug this.. they've got a free download, and it may be good at tracking the behavior of the threads. in the past though, i've always just had more luck using the println() and hunting/pecking around for things that might cause trouble.
|
|
|
|
|
ed
|
Re: Applet freezing problem: any clues?
« Reply #8 on: Oct 14th, 2003, 7:02pm » |
|
just a quick update lest this thread should lead others astray. I *think* I tracked my bug down to a rather boring array out of bounds exception that was only occuring during an unlikely floating point rounding condition, hence it's unpredictable rarity. I was seeing this array exception when running within the P5 environment, but was getting not a sniff of an exception on the console in either the sun or microsoft VM's. [I have a habit of exporting and running within the browser if I want to play for any length of time, hence I was led astray by the apparent absence of an exception].
Hey ho, and onto the next bug[s] 
|
|
|
|
|
|
