hi
there is a button to show you a JList of contents of folder. it is working and show you the contents but after you read a file and press this button again to return to the list , the system freezes and and closes after seconds printing the following message:
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
at java.awt.EventQueue.postEvent(EventQueue.java:250)
at java.awt.EventQueue.postEventPrivate(EventQueue.java:202)
at java.awt.EventQueue.postEvent(EventQueue.java:175)
at sun.awt.PostEventQueue.flush(SunToolkit.java:1931)
at sun.awt.SunToolkit.flushPendingEvents(SunToolkit.java:624)
at java.awt.EventQueue.getNextEvent(EventQueue.java:465)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:245)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
mizmar
March 28th, 2008, 08:18 AM
it seems this methood using alot of memory
when i tried to show the list and do another thing then show it again for many times the system freeze but this time printed diffierent message:
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
at java.awt.image.DataBufferInt.<init>(DataBufferInt.java:41)
at java.awt.image.Raster.createPackedRaster(Raster.java:458)
at java.awt.image.DirectColorModel.createCompatibleWritableRaster(DirectColorModel.java:1015)
at java.awt.GradientPaintContext.getCachedRaster(GradientPaintContext.java:42)
at java.awt.GradientPaintContext.getRaster(GradientPaintContext.java:214)
at sun.java2d.pipe.AlphaPaintPipe.renderPathTile(AlphaPaintPipe.java:106)
at sun.java2d.pipe.SpanShapeRenderer$Composite.renderBox(SpanShapeRenderer.java:42)
at sun.java2d.pipe.SpanShapeRenderer.renderRect(SpanShapeRenderer.java:171)
at sun.java2d.pipe.SpanShapeRenderer.fill(SpanShapeRenderer.java:122)
at sun.java2d.pipe.PixelToShapeConverter.fillRect(PixelToShapeConverter.java:44)
at sun.java2d.pipe.ValidatePipe.fillRect(ValidatePipe.java:58)
at sun.java2d.SunGraphics2D.fillRect(SunGraphics2D.java:2274)
at javax.swing.plaf.metal.MetalUtils$GradientPainter.drawVerticalGradient(MetalUtils.java:326)
at javax.swing.plaf.metal.MetalUtils$GradientPainter.paintToImage(MetalUtils.java:264)
at sun.swing.CachedPainter.paint0(CachedPainter.java:129)
at sun.swing.CachedPainter.paint(CachedPainter.java:88)
at javax.swing.plaf.metal.MetalUtils$GradientPainter.paint(MetalUtils.java:252)
at javax.swing.plaf.metal.MetalUtils.drawGradient(MetalUtils.java:205)
at javax.swing.plaf.metal.MetalButtonUI.update(MetalButtonUI.java:110)
at javax.swing.JComponent.paintComponent(JComponent.java:763)
at javax.swing.JComponent.paint(JComponent.java:1027)
at javax.swing.JComponent.paintToOffscreen(JComponent.java:5122)
at javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:285)
at javax.swing.RepaintManager.paint(RepaintManager.java:1128)
at javax.swing.JComponent._paintImmediately(JComponent.java:5070)
at javax.swing.JComponent.paintImmediately(JComponent.java:4880)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:723)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:679)
at javax.swing.RepaintManager.seqPaintDirtyRegions(RepaintManager.java:659)
at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:128)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
Londbrok
March 28th, 2008, 08:54 AM
By instict would say an infinite loop, but you do manage to get the file list the first time round right? Kinda impossible to say, without the code again. Could it be that you call expensive GUI operations such as repaint() inside the file sniffing loop?
The most basic anatomy for running out of memory is simple...
you have less memory than you would need to access or insert the desired Object, and while at the same time, there is nothing that can be removed to make up this space requirement.
This usually happens when some element of the code is going berserk with creating instaces, loop never ends etc. A recursive file sniffing loop is one of the most usual lairs whence this deamon crawls out of :) ... that being said, least the stacks you posted concern no custom classes or methods, so... I would gestimate, that it is an expensive painting done in a loop.
Compare what the System.out.println("line=" + line) is telling you with what you expect to be getting.
Londbrok
March 28th, 2008, 12:19 PM
well, that post is far from complete. Most of the method is referencing Objects that are not explainable by looking at the method. Also we have no idea from where and how that mwthod is called. Is it called frequently from somewhere?
You got two things a miss here. Fiirst GUI handling, which should not cause a crash (unless the method is called very often), but would possibly make slow GUI. Also the while loop is way insecure, unless every input is sure to end up with "sread" at a point.
fist the gui part...
What is clear, that you are handling GUI elements in that method. Now all GUI in regards to Swing is handled through AWTEventdispatchThread. when handling GUI through method such as what you posted, what you should do, is make sure, that you are dealing with the said AWT thread.
if(!SwingUtilities.isEventDispatchThread()){
SwingUtilities.invokeLater(new Runnable(){
public void run(){
//call which ever method this is.
}
});
//make sure you dont end up doing the method again.
return;
}
The above code is one one way of making sure, sure, sure, that Gui is handled through AWT thread. It creates a new runnable, which AWT thread will take responsibility of at its earliest inconvinience.
I dont know if that helps, since the problem is not quite visible, but still that is a healthy approach. It is public method anyway.
You have a while(true) loop, where the only exit possibility is behing String.equals(...), now you can think of a million possibilities when that loop never ends, right? That is very dangerous loop.
Conside this. Even if your input to the loop was correct. You read one line to check if the line equals "shread". Then you read another, make figure out names out of that... what if that line was "shread"? You would be soooo likely to have never ending loops, depending on how many lines the input happens to have, way unsafe. Dont try this at home!
You probably have a sensible method, addName(...) which simply returns when names param is null? Now the reader has no issue with reading a null line. While you dont make an issue out of it, you have an eternal loop if the end pointer "shread" was skipped. One good thing about Scanner class, is that also throws a NoSuchElementException, when the read in input returns null.
Consider chancing that to while(bfr.hasNextLine()), for example. Something that makes sure, that the loop ends.
mizmar
March 28th, 2008, 01:34 PM
actually i dont know what to say.
i just tested the program again and it was working successfully and never fail.
but i am still interested in securing my code. no way to hope that the bad condition never comeback
mizmar
March 28th, 2008, 01:43 PM
well, that post is far from complete. Most of the method is referencing Objects that are not explainable by looking at the method. Also we have no idea from where and how that mwthod is called. Is it called frequently from somewhere?
You got two things a miss here. Fiirst GUI handling, which should not cause a crash (unless the method is called very often), but would possibly make slow GUI. Also the while loop is way insecure, unless every input is sure to end up with "sread" at a point.
fist the gui part...
What is clear, that you are handling GUI elements in that method. Now all GUI in regards to Swing is handled through AWTEventdispatchThread. when handling GUI through method such as what you posted, what you should do, is make sure, that you are dealing with the said AWT thread.
if(!SwingUtilities.isEventDispatchThread()){
SwingUtilities.invokeLater(new Runnable(){
public void run(){
//call which ever method this is.
}
});
//make sure you dont end up doing the method again.
return;
}
The above code is one one way of making sure, sure, sure, that Gui is handled through AWT thread. It creates a new runnable, which AWT thread will take responsibility of at its earliest inconvinience.
I dont know if that helps, since the problem is not quite visible, but still that is a healthy approach. It is public method anyway.
You have a while(true) loop, where the only exit possibility is behing String.equals(...), now you can think of a million possibilities when that loop never ends, right? That is very dangerous loop.
Conside this. Even if your input to the loop was correct. You read one line to check if the line equals "shread". Then you read another, make figure out names out of that... what if that line was "shread"? You would be soooo likely to have never ending loops, depending on how many lines the input happens to have, way unsafe. Dont try this at home!
You probably have a sensible method, addName(...) which simply returns when names param is null? Now the reader has no issue with reading a null line. While you dont make an issue out of it, you have an eternal loop if the end pointer "shread" was skipped. One good thing about Scanner class, is that also throws a NoSuchElementException, when the read in input returns null.
Consider chancing that to while(bfr.hasNextLine()), for example. Something that makes sure, that the loop ends.
first of all i want to make my gratitute for you.
and i want to ask you is this necessary to secure the using of this infinite loop?
the infinite loop reciveing two values from an array if the array reaches its limit "sread" will be sent to exit from the loop and add the list to the panel.
it is really strange. how sometimes work and somtimes not?
Londbrok
March 28th, 2008, 01:45 PM
Well, if you want to test your code. Best is to approach it with JUnit. There are other, and more sophisticated test frameworks out there, but JUnit is a good start. Of course you can "just test" things out, on the fly, and thats better than nothing too. Still, when making a loop, bells should ring... am I sure this is guaranteed to end, not possble, not like, but dead sure.
A code that sometimes works, and sometimes is sure to fail, is a ticky thing. So, think it through, are you sure the loop can end?
consider this...
Read every second line in a newspaper, ignore the other half. Can you then be sure beyound any doubt, that they did not claim that Elvis Lives? You cant.
Reading a line from a reader means, that unless forced so, that line will not be read again. So you test only every second line for occurence of your end pointer, can you be sure then that you wouldnt miss it?
String.equals(...) in itself is a bad way to test something as important as loop ender. Say by chance you have "shread " instead of "shread" etc. Check against nulls, trim your lines to get rid of extra whitespace, move to more secure classes... Scanner, Properties... xml.
People generally feel, that code succeeding is grand. Equally, if not even more important is that it is guaranteed to fail, when it should.
and yes...
sometimes working sometimes not, is not in any way impossible.
Generally when you are taking in input, your first bastion should not pass through input that the rest of the system can not deal with. And yes... never, ever have a loop that can be infinite.
dlorde
March 28th, 2008, 04:39 PM
Londbrok is right, that loop is just asking for trouble. The loop condition should be checking the return value of bfr.readLine() against null (end of stream) and "sread" (although as londbrok explained, this isn't very clever):String line=bfr.readLine();
while(line != null && !"sread".equals(line)){
String names=bfr.readLine();
if (names == null) {
break;
}
this.h.addName(line, names);
r.addElement(line);
line=bfr.readLine();
}However, even rearranged, this code is clearly not ideal. Good practice would suggest a single read within the loop, and some condition inside it to distinguish a 'names' line from a 'line' line.
Ultimately, it's a design problem. The file should contain the two fields on a single line.
The greatest obstacle to discovery is not ignorance, but the illusion of knowledge...
D. Boorstin
mizmar
March 28th, 2008, 05:53 PM
thank you for valuable additions
may i ask about one particular thing?
which is the best way to send the content of TextArea via OutputStream?
the question is regarding that textarea has many lines.
where area is any JTextComponent, out is any OutputStream. Number of lines does not matter, unless it is really really huge. May need to punch in a few try catches. Remember to end up closing the stream at some point.
mizmar
March 29th, 2008, 04:26 AM
thank you very much lets see how it would be from server side:
String s=String.valueOf(in.read());
where" in " is InputStream?
i think i have to initilize an array to read the bytes but i have no idea how to intilize it and you dont know the required size.
mizmar
March 29th, 2008, 04:39 AM
i am using BufferedReader and PrintWriter how can i deal with this case?
you can prin it without problem but the problem when you try to read it:
bfr.redline();
this command returns just the first line of the file or object
where bfr is BefferedReader
Londbrok
March 29th, 2008, 05:47 AM
You mean reading sockets?
wiring part is basically in no ways different. You have a chunk of data, you write to a stream, flush it to make sure all is there. And eventually at some point, close the stream.
Reading is much more tricky. There are suns tutorials on handlin sckets, that I advice you to read. Basically it boils down to a number of approaches... heresīs some.
Sockets are like keyboard input, as long as the socket is open, you cannot as such tell when the message has ended. Fact that there has been nothing coming in for "quite some while" does not necessarily mean, that all is here. So the question is, when to stop reading?
- have the server and clients agree on protocol to use.
This can be elaborate, and also as simple as each sending first data signifying the size of the actual message (in bytes). Then each end knows how much they should read to get the message. Protocol specs are solely down to the needs of your app.
- Do you need two ways communication? If not, close the socket when done with writing.
So, as such, not a sole can tell you how you should approach it in your application, at least based on that info. Try an approach or two and come back with issues relating to it.
codeguru.com
Copyright Internet.com Inc., All Rights Reserved.