Issue Details (XML | Word | Printable)

Key: GLIFFY-596
Type: Bug Bug
Status: Tested Tested
Resolution: Fixed
Priority: Blocker Blocker
Assignee: Clint Dickson
Reporter: Chris Kohlhardt
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Gliffy

Transcoding of diagram with Chinese char '否' causes out of memory error

Created: 16/May/08 01:19 PM   Updated: 26/Jun/09 11:55 AM
Component/s: Confluence Plugin Integration, Core - Image Transcoding
Affects Version/s: None
Fix Version/s: Gliffy Plugin for Confluence - 1.4.0
Security Level: Anyone may view

File Attachments: 1. File oom (16 kB)
2. XML File oom.xml (16 kB)
3. XML File oom1.xml (0.5 kB)



 Description  « Hide
I've narrowed down the problem, and it seems to be related to this Chinese character:

I've attached a diagram that is experiencing this problem.



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Chris Kohlhardt added a comment - 16/May/08 01:21 PM
oom1.xml - A small test case of the problem
oom.xml - The original diagram that was causing problems
oom - A version of the diagram that works when I replace all instances of the offending character

Tuolin Chen added a comment - 17/May/08 12:48 PM
I'm the original user reported this problem. the character is actually Chinese and it basically means "no", so you can imagine it's used in practically every flow chart we have. Since not every one of them is causing the problem, it seems to me that it is this character combined with some other stuff that is causing the problem.

Chris Kohlhardt added a comment - 03/Jun/08 06:10 PM
Moving these issues to Confluence Plugin release 1.4 since this is the next version being released.

Chris Kohlhardt added a comment - 10/Jun/08 09:07 PM
Exact steps to reproduce:

Environment:
Confluence 2.8.0
GPFC 1.4-RC1

I'm pretty sure any version of Gliffy/Confluence will create this error

  • Create a new confluence page
  • To the new confluence page, add the attachment oom1.xml (attached to this issue)
  • Edit the confluence page and add this gliffy macro:
{gliffy:name=oom1.xml}
  • Save the confluence page.

Notice that:

  • The Confluence log repeats the following debug line forever:

2008-06-10 19:06:19,099 DEBUG [http-8280-Processor8] [gliffy.core.svg.SVGTextWrapper] wrapText iteration:0

The out of memory error doesn't happen as quickly now because I added the debug code, but the problem is still the same. The counter is stuck at zero.


Clint Dickson added a comment - 11/Jun/08 11:59 AM - edited
I tried these steps to reproduce on my Windows machine and still don't get the issue. It never reaches the Debug output and only loops once.
I'm probably not seeing the issue because of the slight difference in the JVM's value of FontMetrics to find character width. I'll continue to look into a fix with the assumption it fails.

I think the issue might not be the character itself, but that we are detecting the width of the text shape containing the character to be Less or exactly the same in width as the character. (This kind of makes sense since it is the "NO" character and its in its own text shape) This was similar to the issue when we saw this problem before. As a test, you could try increasing the width of the text shape in the UI holding all of the solo "No" characters to see if the problem goes away.


Chris Kohlhardt added a comment - 11/Jun/08 12:11 PM
If you want, we can pair program this.

You might also consider running Confluence with JDK 1.4.2, as that's what I'm running and I'm able to reproduce the issue.

I tried reproducing the issue on gliffy02: no dice.

I'll contact the original reporter to see if he has more information.

-chris


Clint Dickson added a comment - 11/Jun/08 12:21 PM
Ya, pair programming might be a good plan. Let me do some more evaulation of the code first.

I am running Confluence on JDK 1.4.2_13. Also, the Fonts on Windows may be causing a discrepancy.


Clint Dickson added a comment - 11/Jun/08 12:48 PM
I've been able to recreate the issue by adding the character to a really thin text shape. Looking into a fix.

Clint Dickson added a comment - 11/Jun/08 04:17 PM
added a special check at beginning of loop if no progress is made to attempt to wrap a line of text after first try