java.awt.geom Area.Intersect\Area.Subtract locking up calling thread - seems to be in an endless loop.

[jeremy_]

I have run my code through a profiler and also used the following debugging technique to infer that this main thread in my application is being locked up due to a call to Area.Subtract (Also Area.Intersect - for some reason I can't reproduce the Area.Interect occurance right now - but I believe the call-stack looked similar to Area.Subtract.)

Call-stack when breaking thread in endless recursive structure underneath the Area implementation.

StrictMath.acos(double) line: not available [native method]	
Math.acos(double) line: 187	
Order3.TforY(double) line: 355	
Order3(Curve).compareTo(Curve, double[]) line: 910	
Edge.compareTo(Edge, double[]) line: 90	
AreaOp$SubOp(AreaOp).pruneEdges(Vector) line: 278	
AreaOp$SubOp(AreaOp).calculate(Vector, Vector) line: 159	
Area.subtract(Area) line: 260	
 
From here, callstack reaches into my engine's code, where the subtract\intersect method was invoked
Lightmap.enqueueRender(GraphicsConfiguration, Rectangle, Matrix2X2, int, int, float) line: 182

1. Execute application
2. Works for a seemingly random period of time
3. Locks up - no response from main thread
4. Break the main thread (pause it)
5. Call-stack shows I am executing inside of Area.Subtract\Area.Intersect . I step to return, continuously, until I attempt to step out of AreaOp$SubOp(AreaOp).pruneEdges(Vector) where the thread resumes execution and never returns (suggesting the looping structure that isn't existing must be somewhere in AreaOp$SubOp(AreaOp).pruneEdges(Vector)

My question is: Can this behavior be due to unexpected data being used when invoking the routine (Is it possible that my caller is feeding the routine invalid data causing this behavior?) Either way, I think this should be considered a 'bug' in the implementation since locking up should never really be acceptable in the java.awt library.

However, I am simply looking for a temporary work around for this function (or a different implementation in an open-sourced library?) because this sort of area addition\subtraction etc is rather critical form my engines lighting subsystem.

Thanks.

--- Update ---

I found a way to reproduce the thread-locking caused by the Area.Subtract routine - I can perform logging or try and setup a small reimplementation of the issue. I would rather not though because I'm pretty busy so instead I'll just wait for a request (if it is needed)

[GregBrannon]

When you can afford the time, providing the small bit of code that duplicates the issue would be best.

Mostly, I need to see the program architecture: if multiple threads (either the normal ones or others created by you), how many, what are they doing, how could they interfere with each other, either accidentally or on purpose, etc.?

[jeremy_]

When you can afford the time, providing the small bit of code that duplicates the issue would be best.

Mostly, I need to see the program architecture: if multiple threads (either the normal ones or others created by you), how many, what are they doing, how could they interfere with each other, either accidentally or on purpose, etc.?

Alright, I'll see if I can figure out what sort of data is being fed to these objects is causing the main thread to enter the loop and try and recreate it in a small bit of code.

For what its worth, I'm pretty sure it isn't a thread synchronization issue since after I attempt to break on return for that function, AreaOp$SubOp(AreaOp).pruneEdges(Vector), I don't hit the break because it never returns. So then I hit pause again, and I can see it has entered the same call hierarchy again that I can step out of until I reach AreaOp$SubOp(AreaOp).pruneEdges(Vector) - so I don't think it is waiting on a synchronization object (also my applications CPU usage shoots sky-high).

Aside from that, I only have one thread (that I've created) running anyways.

Also, doing some research I found this:
http://osdir.com/ml/java.classpath.b.../msg00071.html
That code in particular doesn't hang my thread - but there have been problems with this implementation in the past. I'll find my data-set though that hangs (like I said, that code doesn't seem to cause problems for me, but I will find the particular set of data that does - I am just pointing out it has been problem code before)

[jeremy_]

When you can afford the time, providing the small bit of code that duplicates the issue would be best.

Mostly, I need to see the program architecture: if multiple threads (either the normal ones or others created by you), how many, what are they doing, how could they interfere with each other, either accidentally or on purpose, etc.?

Alright, I've managed to recreate it in an isolated environment (the code looks like complete nonsense since it's just a bunch of unrolled loops with the area operations isolated):

*EDIT*
I have also confirmed that this is also the same source for hanging on intersect (just replace the subtract operation with intersect)

package UnitTest;
 
import java.awt.Polygon;
import java.awt.geom.*;
 
public class Main
{
 
	public static void main(String[] args)
	{
 
		AffineTransform lightTransform0 = new AffineTransform();
		lightTransform0.translate(192,463);
		lightTransform0.scale(1.0F, 1.0F);
 
		Ellipse2D ellipse = new Ellipse2D.Float(-192, -96, 384, 192);
		Area lightArea = new Area(ellipse);
		lightArea = lightArea.createTransformedArea(lightTransform0);
 
		///////////////////////
		Area obstructionArea = new Area();
 
		Polygon obstructionPolygon0 = new Polygon();
 
		obstructionPolygon0.addPoint(176, 384);
		obstructionPolygon0.addPoint(208, 384);
		obstructionPolygon0.addPoint(208, -406);
		obstructionPolygon0.addPoint(176, -406);
 
		Area obstruction0 = new Area(obstructionPolygon0);
		obstruction0.intersect(lightArea);
		obstruction0.subtract(obstructionArea);
		obstructionArea.add(obstruction0);
 
		/////////////////////////
 
		Polygon obstructionPolygon1 = new Polygon();
		obstructionPolygon1.addPoint(96, 479);
		obstructionPolygon1.addPoint(96, 449);
 
		obstructionPolygon1.addPoint(-864, 459);
		obstructionPolygon1.addPoint(-864, 489);
 
		Area obstruction1 = new Area(obstructionPolygon1);
		obstruction1.intersect(lightArea);
		obstruction1.subtract(obstructionArea);
		obstructionArea.add(obstruction1);
 
 
		//This line should cause a hang!
		lightArea.subtract(obstructionArea);
 
    }
}

[jeremy_]

I've submitted this a bug report to oracle, I'll be contacted within the next couple of days if it is a valid report. I got someone else to execute the code above and it does hang for them as well.

For anyone who stumbles upon this thread, until then you can use LGPL Java Topology Suite for your Geometric calculations.

[GregBrannon]

I'll admit that I don't have a clue what you're doing, but I noticed that if line 16:

lightArea = lightArea.createTransformedArea(lightTransform0);

is commented out, the example completes. Maybe the transformation can be done after the subtraction.

If I understood better what you were doing, I'd play with the numbers to see if the transformation is causing a corner case that can't complete the subtraction successfully, but maybe you could play around with it.