Actually, I'm pretty sure I've already fixed this (and many other bugs like it) with this patch: http://icedtea.classpath.org/hg/icedtea6/file/589610636e32/patches/openjdk/6967436-6976265-6967434-pisces.patch

Unfortunately, that patch is only in HEAD, and not in icedtea6-1.9, which is what you're using, so I have to apologise for this oversight of mine. I'll backport the fix into 1.9 first thing tomorrow.

However, just to be sure, could you please give me the exact line coordinates that cause the crash, along with the current transform in the Graphics object being drawn to? I need these because even though the exceptions won't be thrown with my patch (because in it I use floating point arithmetic instead of ints and longs), there's still a possibility that the divide by 0 is there, and exception or not, those are bad.

Thank you,
Denis.

(In reply to comment #1)
> Actually, I'm pretty sure I've already fixed this (and many other bugs like it)
> with this patch:
> http://icedtea.classpath.org/hg/icedtea6/file/589610636e32/patches/openjdk/6967436-6976265-6967434-pisces.patch
is there some (relatively easy) way for me to try that patch?
> Unfortunately, that patch is only in HEAD, and not in icedtea6-1.9, which is
> what you're using, so I have to apologise for this oversight of mine. I'll
> backport the fix into 1.9 first thing tomorrow.
I guess this would be another way to try it, but how long will it take
before this would appear in my yum update?

> However, just to be sure, could you please give me the exact line coordinates
I'm not sure what you're asking for - aren't the lines shown in the backtrace?

> that cause the crash, along with the current transform in the Graphics object
> being drawn to? I need these because even though the exceptions won't be thrown
> with my patch (because in it I use floating point arithmetic instead of ints
> and longs), there's still a possibility that the divide by 0 is there, and
> exception or not, those are bad.
... looks like the /0 occurs the 5th time at line 957 ...
Perhaps you could tell me how to get eclipse to break at the exception so I
can look at stuff there.  It's hard to be sure I'm looking at the right data
if I try to sneak up on it.
Right now I'm looking at the 5th call to 957 and I see in PiscesRenderingEngine stroketo line 181, src seems to be the line we want to draw, at is
(now trying to copy stuff without use of copy/paste!)
[[.0029, 0, .359], [0, .0029, 60]]
I then followed it down to linelength and the arguments to that didn't seem so strange, but I got the exception.

Ok, here it is
    long lineLength(long ldx, long ldy) {
ldx=-5809, ldy=0
        long ldet = ((long)m00*m11 - (long)m01*m10) >> 16;
        long la = ((long)ldy*m00 - (long)ldx*m10)/ldet;
m00=194=m11, m01=0=m10
ldet=0

> is there some (relatively easy) way for me to try that patch?

Well, you could try
hg clone http://icedtea.classpath.org/hg/icedtea6
and building it, which is pretty straightforward. Make sure you get all the
dependencies first: http://icedtea.classpath.org/wiki/FedoraBuildInstructions
If you do that, and it works, then we can be certain that that patch does fix
the problem.

Or, better yet, it would be great if you could give me the program that causes
the bug. Source code would be nice but class files should also be ok.


> Ok, here it is
>     long lineLength(long ldx, long ldy) {
> ldx=-5809, ldy=0
>         long ldet = ((long)m00*m11 - (long)m01*m10) >> 16;
>         long la = ((long)ldy*m00 - (long)ldx*m10)/ldet;
> m00=194=m11, m01=0=m10
> ldet=0

Well, the stacktrace shows the line where the exception was thrown, and there's only one division there, so obviously ldet was going to be 0.

Anyway, what's happening there is pretty much an underflow. The transformation matrix entries are originally very small doubles (or floats). Then m00, m11 are computed as m00=(int)(65536*a00), which turns out to be 194. When we do m00*m00, we're effectively multiplying two very small numbers, and the result is 0.

(In reply to comment #3)
How long do you think it'll take for the patch to arrive via yum update?
Also how can I tell when the version I get from yum is supposed to contain the fix?
 
> Or, better yet, it would be great if you could give me the program that causes
> the bug. Source code would be nice but class files should also be ok.
The trouble is that there's a huge amount of code, it's not trivial to extract the part that's giving the problem, the code relies on a database, etc.
If you like, I can just give you (off bugzilla) a url and login and some
short instructions to reproduce the problem.
But if the case I reported is fixed then I wouldn't worry about it.
 
> Anyway, what's happening there is pretty much an underflow...
And this is fixed in your version?

> How long do you think it'll take for the patch to arrive via yum update?
> Also how can I tell when the version I get from yum is supposed to contain the
> fix?

If you're using the GUI updater, if you select the openjdk update you should be able to see it under NEWS. As for when it will arrive, I'm not sure.

> The trouble is that there's a huge amount of code, it's not trivial to extract
> the part that's giving the problem, the code relies on a database, etc.

Did you try building the source checkout?

> If you like, I can just give you (off bugzilla) a url and login and some
> short instructions to reproduce the problem.
> But if the case I reported is fixed then I wouldn't worry about it.

That would be nice.
 
> > Anyway, what's happening there is pretty much an underflow...
> And this is fixed in your version?

Yes. I mean, I don't want to speak prematurely, but I'm as sure as I could be without testing your specific reproducer.

Ah, great. I was able to reproduce this with the default java and java plugin on F13. Then I ran it with the latest icedtea6, and everything looked fine, so I'm closing this.