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.
--- 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)