• You are here:  
  • Home
  • Q&A
  • Q&A
  • PowerBuilder
  • Application crashed before reaching the PowerBuilder GDI Resource limit.

Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (4)

Resolved Application crashed before reaching the PowerBuilder GDI Resource limit.

  1. Issue
0
Votes
Undo
  1. Venugopal r
    Venugopal r
  2. PowerBuilder
  3. Monday, 10 October 2022 18:41 PM UTC

Hi Chris and Team,

I have already reported bug ID 9005. When the application was further examined, it was discovered that additional GDI resources were being accessed every session.
I discovered the GDI resource and memory details below after turning on scripting. It appears that RAM is sufficient because system crashes when it reaches about 9K GDI resources. According to Windows' advice, I upped the "GDIProcessHandleQuota" limit in the Registry from the default 10000 to 16384, but the system is still crashing. Why PB collapsed while having a limit is quite unusual. I hope we need to address this. Would you kindly help?

The screen shots for application memory, GDI resources, and GDI guidelines are shown below.

 

Thanks in advance.

 

.NET DLL Importer - Could not file or assembly
Regarding printing slow
Responses (4)
Venugopal r
Venugopal r Accepted Answer Pending Moderation
  1. Monday, 29 January 2024 07:18 AM UTC
  2. PowerBuilder
  3. # 1

Hi, Yes identified the resolution.

 

Hope your application reached the OS level GDI and UO limit. So increases the limit from 10K to max in your registry of the following attribute highlighted in yellow.

Registry path has available in ticket description. 

 

 Thanks,

Venu

Comment
There are no comments made yet.
Jeff Martin
Jeff Martin Accepted Answer Pending Moderation
  1. Thursday, 25 January 2024 17:46 PM UTC
  2. PowerBuilder
  3. # 2

Has there been any resolution or suggestions on this topic? We are seeing similar behaviours.

Comment
There are no comments made yet.
John Fauss
John Fauss Accepted Answer Pending Moderation
  1. Tuesday, 11 October 2022 01:37 AM UTC
  2. PowerBuilder
  3. # 3

Hi, Venu -

I have many questions, but don't know where to start...

What do you mean by "...additional resources were being accessed every session."? Does this app run on Citrix? Remote desktop? User's desktop? Please elaborate.

How many PBL's and roughly how many PB objects in those PBL's?

Is this an MDI app? Was it developed with a framework? If so, which? Has this framework been migrated from PB version to PB version without replacement? If so, how long has it been since a new version/release of the framework was introduced?

How many "sessions" are open when the GDI resource handle count approaches 10,000?

How many windows are open when the GDI resource handle count approaches 10,000?

Are these windows utilizing tab controls? If so, roughly how many tab pages and approximately how many controls (command buttons, DataWindow control, static text, etc. reside in each tab page?

I work on a relatively large (but not huge) traditional MDI client/server app based on the PFC, and with more than a dozen complex sheet windows open, several with tab controls, the GDI resource count barely approaches 1,000. I think you're going to have to monitor GDI resource usage while the app is being used to gain insights into how these resources are being allocated, and also why they are not being returned/released.

Comment
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Wednesday, 12 October 2022 13:57 PM UTC
Hi John;

FYI .... : I worked over the past weekend with Venu and shared some of my STD Framework's PowerScript code that monitors App memory, resources and GDI usage. The problem stems from the fact (AFAIK) that this mature App opens many Tab Pages and then has GUI controls within those TP's. Once Venu had my GDI Resources code in place, we were able to determine that his App was well beyond the 9,000 plus GDI resources consumed.

That led us to the conclusion that the App was probably exceeding the MS-Windows default address space limit of 10K GDI resources.

Once Venu changed the O/S GDI resource default from 10K to a much higher value, then the App ran OK.



Since the App ran OK in the PB 12.x versions of PB - the GDI issue seems t be aggravated by the newer PBVM of Appeon PB in that the PBVM consumes much more GDI resources in it's current architecture than the latter Sybase versions and even possibly is holding on to these resources longer than before. Just my guess at the moment.

Engineering is now looking at this information.

Regards ... Chris
  1. Helpful 1
John Fauss
  1. John Fauss
  2. Wednesday, 12 October 2022 14:50 PM UTC
It's good to learn you were able to help Venu analyze his issue and good to hear that Engineering is engaged on this issue as well. I very much appreciate the update, Chris!
  1. Helpful 1
There are no comments made yet.
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Monday, 10 October 2022 19:19 PM UTC
  2. PowerBuilder
  3. # 4

Hi Venu;

  I am glad that you were able to adopt my STD Framework's Memory & GDI monitoring code!

   I'm back in the office tomorrow AM & will review and comment on your ticket. I wonder if the GDI registry setting though is being ignored. Let's see what Engineering says.

Regards ... Chris 

Comment
Venugopal r
  1. Venugopal r
  2. Monday, 10 October 2022 19:35 PM UTC
Sure Chris, The study of your OrderEntry framework code is truly wonderful and a great experience.

Thanks a lot for your great support.

Thanks,

Venu
  1. Helpful
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Wednesday, 12 October 2022 13:50 PM UTC
Hi Venu ...

You are most welcome!

I updated your ticket with more information. Hopefully, that will help Engineering with this issue.

Regards ... Chris
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.