1. Olan Knight
  2. PowerBuilder
  3. Friday, 1 March 2019 01:04 AM UTC

PowerBuilder v12.1, build 7055
Oracle 12C
Non-PFC PB client application


We have ten utilities that are baseline PowerBuilder applications. Some use OLE to open Excel  to import an Excel  file, others simply import test files. All of them use some Windows APIs to perform various tasks, and most of those are FIND/GET APIs.

The utilities are hosted on a Citrix box, and that's how they are accessed by the users.

Every so often, one of the users starts having more and more difficulty accessing the utility. Once her Windows User Profile is rebuilt, the utility is again accessible. After 2-4 weeks of activity her Profile somehow gets corrupted. This occurs regularly. It only seems to happen on one of the 10 utilities; but to be fair it's the most used utility.

Q:  Does anyone have any idea how a non-PFC application could be corrupting a Windows User Profile?
     Is that even possible?
     Is there any other way the Windows User Profile could be getting corrupted?

Thanks,

Olan

~~~~~~~~~~~~~~~~~

The utilities use the following FIND/GET Windows APIs, all from LIBRARY "Kernel32.dll" except as noted:

FUNCTION uint      FindWindowA            
FUNCTION ulong    GetEnvironmentVariableA
FUNCTION boolean GetComputerNameA       
FUNCTION boolean GetUserNameA       
Function Boolean    GetFileTime            

FUNCTION int        GetModuleFileNameA    
FUNCTION long      GetCurrentProcessId    

Function Boolean   GetFileTime          
FUNCTION long      FindFirstFileA         
FUNCTION boolean FindClose              
FUNCTION boolean FileTimeToLocalFileTime
FUNCTION boolean FileTimeToSystemTime

FUNCTION long      GetFileVersionInfo   
Function ulong       GetProcessHeap      
Function ulong       VerQueryValue        


They use the following non-FIND/non-GET Windows APIs:

Function boolean MoveFileA  
Function ulong    HeapAlloc   
Function long      HeapFree    
Subroutine         RtlMoveMemory
Function ulong    strcpy      


Julian I. Accepted Answer Pending Moderation
  1. Friday, 6 December 2019 07:53 AM UTC
  2. PowerBuilder
  3. # 1
Hi Olan,

I think we could have a similar problem. Did you find the solution?

Our application crashes randomly on some client PCs. When this happens, 
if the user reboots the PC or we access in the same PC with another user
and do the same operation in the application, it works.

It seems that this happens more often to users who keep the windows session open several days.

Regards,
Julián

Comment
There are no comments made yet.
Olan Knight Accepted Answer Pending Moderation
  1. Friday, 6 December 2019 15:04 PM UTC
  2. PowerBuilder
  3. # 2

Julian -
   Sadly, we have not yet determine the cause of this issue. It's difficult to track because it occurs so infrequently and we have no idea on how to force the error.

   You know the saying, "if we can duplicate it we can fix it, but if we cannot duplicate the error then...".


Olan

Comment
There are no comments made yet.
Roland Smith Accepted Answer Pending Moderation
  1. Friday, 6 December 2019 16:19 PM UTC
  2. PowerBuilder
  3. # 3

Maybe the profile is getting too large due to having many files stored in it.

Comment
  1. Olan Knight
  2. Friday, 6 December 2019 16:47 PM UTC
That'san idea worth checking out. Thanks, Roland!



Olan
  1. Helpful
  1. John Raghanti
  2. Friday, 6 December 2019 18:21 PM UTC
Yes, definitely check the temp space for the user, browse to: %temp%



We had issues in the past, particularly with FindFirstFileA and directories with large file counts.
  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Friday, 6 December 2019 19:27 PM UTC
  2. PowerBuilder
  3. # 4

Hi Olan;

  FWIW: The xxxxxxxA API's should become xxxxxW as PB is now fully Unicode. Its probably not the source of your stability issue, but I have found that some "A" API's will no longer work properly under newer O/S versions like W10 and/or W2016/2019. The same when you run the App EXE "as Admin" mode. You have to careful of that mode as W10 imposes run-time restrictions on certain API's.

  Your current problem (and even Julian's) though could be due to "orphaned" NVUO's that never get destroyed (even by garbage collection) and eventually over time (aka Long Running Apps), get to the point where the App's current address space runs out of usable memory.

  I am now just addressing this issue in my frameworks as they now track all NVUO's (standard and custom). The idea was to provide a guide to the PB developer at debug time or when running the App in "debug mode" of all the NVUO "creates" that were performed, what NVUO's are in memory at a debug break point and also importantly, what NVUO's are hanging around and never get destroyed until at Application close. Hence a road-map to make sure that your PowerScript code is always cleaning up after itself (in other words - don't trust garbage collection).

  Here is an example test case. My framework uses a DataStore to track what Menu Items the user navigates through as a statistic gathering feature. The menu item stats are recorded in a DataStore and then logged on destruction. The menu's DSs get destroyed when the menu is destroyed (OK, menu's do not have constructors or destructors events but, my framework adds support for these - "kool" or what). Now if I remove the clean-up code from my ancestor menu's destructor, as follows:

    io_ds_stats.Reset ( )
    io_ds_stats.DataObject    =    ""
    // Destroy io_ds_stats

  Since the framework now tracks all NVUO's, here is what the framework's Debug Trace looks like after opening a few Windows and then closing them...

 Even minimizing the App's MDI frame & restoring or calling Garbage collection method - the orphaned NVUO's are still instantiated and keep growing. They are never cleaned up by the PB run-time (probably a bug but, none the less an issue). So if this is a long running app, one that CREATE's DS's or other NVUO types using a local variable - especially in a big Loop OMG), then 100's if not 1,000's of these orphaned NVO's will grow over time. Once they grow to the point where the PB App has no more "safe" memory within its address space ... WHAM-O - your app instantly crashes and most likely, with no error message from the PBVM and/or Mr Bill (aka Windows O/S).

Food for thought.

Regards ... Chris

 PS: This NVUO tracking code also works in PowerServer Web and Mobile Apps!

 

Comment
  1. Roland Smith
  2. Saturday, 7 December 2019 03:14 AM UTC
I would imagine that a 64 bit build would give the app more memory and might alleviate the issue.
  1. Helpful
  1. Julian I.
  2. Sunday, 8 December 2019 18:50 PM UTC
Thank for your help !!! The tool you are working on, will undoubtedly be of great help.

Now i will review the destruction of the objects in our app ...

A curiosity, do you reset de DS and deallocate DataObject before Destoy it? Is it better to free memory?



Regards.
  1. Helpful
  1. Chris Pollach @Appeon
  2. Sunday, 8 December 2019 19:53 PM UTC
Hi Julian;

Yes, you can see the framework's code in the menu destructor that I posted earlier. It clears all buffers & frees this memory using a Reset() command. Next, it releases the DWO & it's memory via assigning the DataObject to empty. Then, finally releasing the DataStore. The framework disposes of all DataStore's in this manner. Just to show you how good this works, my framework was used by a PB shop that built apps that ran 24/7 for over a year without shutting down. They never crashed and were handling super large data results & blob datum. The apps ran dynamically up to 48 instances of itself at a time, as Windows system tasks.

Regards ... Chris.
  1. Helpful
There are no comments made yet.
John Raghanti Accepted Answer Pending Moderation
  1. Monday, 9 December 2019 13:31 PM UTC
  2. PowerBuilder
  3. # 5

If you're looking for a memory leak where you're not destroying created objects, one of the things you can do is look at GDI objects on the Windows machine. See attached image of the task manager.

In Task Manager (Details tab on Windows 10), add GDI Objects to the viewed columns. If this number keeps growing the longer the application is open, then things are not being destroyed properly. 

A couple years back on a Windows 7 machine (don't remember if it was 32 or 64 bits), once that number got to around 10,000, the application would GPF. I haven't played with this recently, so I don't know what the new OS thresholds are.

Generally, you should see the number grow when opening windows, and upon closing, you should see the number shrink.

 

Attachments (1)
Comment
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.