TD-17029: TD/RB 6.0 SP4 loses GDI handles on warnings

[Nils Jänicke]

Printing a report with custon settings of the paper size causes a warning message box that the paper size is exeeded. I can avoid the message box byusing the option RPT_PrintNoWarn at the TD print command SalReportPrint(). In both cases the application uses two GDI handles and the memory usage increases. Without getting the warning (if the paper size matches to the printer settings) all used GDI handles are given back (it increases and decreases and all is ok).

One of our customers prints many different labels at a batch procedure and when the application runs longer time and it has printed many labels, the application crashes, sometimes with low memory, sometimes with a "Mismatch in input variable #0" message.
Here is a little test case, stop your printer (or fill up the paper tray ) and see the behavior of the GDI handles and memory usage at the task manager using the report with custom paper settings and using the report without.

[Nils Jänicke]

Even if the report prints without warning the memory usage increases -> I think there is a memory leak.

[Nils Jänicke]

After printing about 4800-4900 reports with mismatch at paper size (PRT_NoWarn) the application hangs.
After printing about 14016 reports without warnings the memory usage has reached 495816 K and it does not print anymore.

[micsto]

Install more memory

[Nils Jänicke]

Install more memory

That's no option. I do have a new WIN 7 64 Bit machine with 12GB memory, but this test case also ends on this machine with printing on a memory usage of less than 1/2 GB.

[micsto]

I was just joking...

[Jeff Luther]

I asked internally about this and got this reply from the TD developer who works with ReportBuilder:

Take a look at the report option. There is an option in the report “Cache Preview Pages”. If this option is enabled, RB will cache each page to improve the performance, the price is 2 GDI objects for each page.
I suspect the user enable this option as he exhausts the machine with about 4800 pages ( the default limit is 10,000 on Windows ). This is not a leak, once the printing is done, the GDI objects would be recycled. Disable/uncheck this option and see whether the “leak” goes away.

I did take a look, and your test qrp does have that Cache Preview Pages option checked:

CachePreviewPages-Option.png

Try unchecking the report and see if this improves things for your customer. If not, let us know the details and I'll add a defect for this issue.

BTW, I do see GDI and memory go up as I 'printed' 100 reports. But I didn't need to print 100 times to my HP printer to do this. The developer gave me a good link to a PDF driver printer: http://www.novapdf.com/
that allows you to prefine a PDF output name and 'overwrite' the existing PDF. That was I was able to print 100 times to the same single PDF file. Good for testing like this!

[Nils Jänicke]

Did you read my message? It is not the printing that looses GDI handles and it is not a problem with many pages. The warning message that the paper size is exeeded also causes a GDI leak of 2 objects and they are also loosing if the option RPT_PrintNoWarn is set and no message is shown. And these GDI handles are not recycled, so this is another issue.
I've tried to switch the cache off as you said, but it has no effect, the report also looses GDI handles and memory until it crashes.

[Jeff Luther]

Nils - I deleted your last message, since the text was not necessary and I do not need constant reminders. As you know, we are very busy and our policy is that we try to get to help out with issues whenever we can.

I've tried to switch the cache off as you said, but it has no effect, the report also looses GDI handles and memory until it crashes.

Then it sounds like something else is going on. The comment I passed along to you in my previous msg. came right from the TD developer who works with RB internals. If what he said isn't true for you ("but it has no effect") then something else must be going on and will need to be investigated.

BACK TO YOU, NILS: I need a test case that shows EXACTLY this problem and exactly instructions on how to duplicate it. I am not able to print out 4800-4900 reports, much less 14000+ ! I tried to simulate this with that PDF driver I gave you info. on.

Kindly stop sending private emails -- I and other t/s engineers get here when we can (it is a difficult time now, because of Holidays) -- and no more msgs. ALL IN CAPS.

[Nils Jänicke]

Hi Jeff,

I've sent you a testcase. If you are starting the program (you can hold printing on the window's printer queue and after the test you can delete all entries in the printer queue) and when you open the task manager you can see that the GDI handles increases until they are reaching 9999, then the app crashes. The GDI handles are never given back. And this behavior only occurs when the printer paper settings do not match the paper settings of the printer (maybe on a PDF printer driver this problem does not exist). Regardless if the warning message box is shown or if it is supressed by using PRT_NoWarn option of the printer flags it looses 2 GDI objects on every print.
We have a customer who prints lables for their products and if the app runs multiple days sometimes it crashes because of less memory and too many GDI objects. So I want to know if Unify has found something to fix with the next SP.

And Jeff, the first message for this issue I've sent Fri 9th and exactly one week and only after I've sent a private message it came an answer from you. Then I've answered that this didn't help me because it is another bug and exactly one week later and after another private message there came the next answer. A little answer "we are working on that problem" or "we can't reproduce this problem because... and plese send me..." would be better and I would know that someone has read the message I've sent.

So have a merry christmas and I will try to be more patient...
Nils

[Jeff Luther]

After printing about 4800-4900 reports with mismatch at paper size (PRT_NoWarn) the application hangs.
After printing about 14016 reports without warnings the memory usage has reached 495816 K and it does not print anymore.

Have you ever considered correcting this problem -- change report paper size in the QRP, prompting the user to cancel and get a correct printer, etc. -- rather than let it continue in the code until some hang/crash occurs?

FYI, I am going to run this issue to our tech help group internally... I did that and it's agreed to get this in as a defect to be looked at by development. New defect for this issue is: TD-17029