[#5471] - Infinite Loop Crashes Server - 1 Page Report - 1 Result - Data causes overflow

Category:
Bug report
Priority:
High
Status:
New
Project: Severity:
Critical
Resolution:
Open
Component: Reproducibility:
Always
Assigned to:
0

Using JasperReports 4.0.2 or 4.1.2(haven't tried it in Jasper 3x), we run into an infinite loop in JRVerticalFiller.fillPageBand() and specifically in the while (band.willOverflow()) loop. This looping eventually causes the server to get OutOfMemoryErrors.

AttachmentSize
Binary Data JasperBug.zipx18.42 KB
crykal79's picture
Joined: Jul 14 2008 - 4:35am
Last seen: 13 years 4 months ago

10 Comments:

#1

We have run into the same problem with version 3.7.6 in my project without being able to solve it.

#2

Same with me. This bug sometimes crash the server.

#3

We are facing the same problem. Because of this problem some reports do not get generated and it sometimes makes the server crash. If it happens in a report that is frequently accessed, the server will crash several times in the same day.
Depending on the report's data, the report will work or it not will work leading the server to crash.
Does it have any solution?

#4

This problem is due to wrong report design. However in any case, this behaviour is not acceptable in a production environment. Currently it is kind of hard to check if the report is in a loop, it seems doable but it might be costly and complicated to implement for sure.
My suggestion is to you, use swap file virtualization and implement a basic check for swap file usage per report.

If you use JRSwapFileVirtualizer to virtualize, you can check serialized object data sizes easily. You might need to use a weakhashmap (key = master virtualization context, value (total serialized object size).

But keep in mind that, serialized object model size is not even close to generated report size. So you might need set maximum usage to 3-5GB if you happen to have 200+mb reports.

Except file virtuazer it seems same check implemention can be done without any cost. But with file it is still doable bu so much cost. So dont use it.

#5

Same error, server eats up all available memory in 5 minutes. After that we are forced to restart it.
We can use property MaxPagesGovernor.PROPERTY_MAX_PAGES to bypass problem, but this is just workaround, not a solution.

#6

I suppose i have the same error. Could reduce the error to a very simple report which probably makes debugging easier.

Report ends up with inifite number of pages an crashes our server after half an hour. Tested against Studio version 6.3.1.

AttachmentSize
Binary Data rep_vz_vrao_sendeprotokoll_1.jrxml6.19 KB
#7

@michael.froehler, your report ends up in an infinite loop because the text elements have isPrintWhenDetailOverflows="true". Do you actually need that flag to be set? Resetting would probably result in the report completing normally.

Regards,
Lucian

#8
  • Priority:Urgent» High

Hi Lucian,

Thank you for your fast answer. The fact with "printWhenDetailOverflows=true" I have noticed already. The problem with our reports is that it also depends on band heights and content of the text fields (stretchWithOverflow=true) if the report works or runs infinite.

We had the case that the person who designed and tested the report had a working report and after two years of usage a user calls the report with a certain content that makes it run infinitely.

In my example: If you adjust the content (that normally is read from a database) of the second text field (make it longer or shorter) the report will again work correctly - even with "printWhenDetailOverflows=true".

The problem is that the report designer actually cannot see if he has created a report that crashes in case of a specific content or not.

Hope this helps you to classify this behaviour and maybe find a solution. Maybe a solution could also be not to use "printWhenDetailOverflows=true" when "stretchWithOverflow=true" automatically.

Regards,

Michael

#9

I have run into a similar issue with 6.4.0. In my use case I have a subreport containing a chart with overflowType="NoStretch" and height of 150 but the height of the subreport's chart is 250. i am trying to scale down the chart in this report as i need it 250 in another report and 150 in this report. with this combination of heights and overflowType="NoStretch" the report never completes rendering

#10
  • Assigned:nobody»
Feedback
randomness