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

Resolved How to debug 64-bit app that is "leaking memory" when exiting

  1. Issue
0
Votes
Undo
  1. Aimee Stephens
    Aimee Stephens
  2. PowerBuilder
  3. Tuesday, 14 December 2021 23:52 PM UTC

The 32-bit version of the app works fine and when we first migrated and created the 64-bit version of the app using PB 2019 the app loaded and exited and everything in between ran with no issues.  Since then we've upgraded to 2019 R3 Build 2728 and now when I exit I get an error message that the application has stopped working and please close the program.  It also gives me the option to debug the program.  In doing so I get the attached screenshots.  I should mention, we use a dedicated server to build our exes and it is still running the original PB 2019.  We also user PowerGen version 11 to create our exes.  We do NOT have any databases connected to the application.  Everything is stored externally and is retrieved through COBOL via a 64-bit DLL.  Our system administrator is adamant that I should be able to debug through the code.  I've tried explaining that the IDE is 32-bit and can't be debugged in 64-bit mode and gave her the .dbg trace file that shows everything, including the environment, has been destroyed.

We did migrate from PB 7 to PB 2019 which is a huge migration but there were zero errors.  The migration added the "Alias for" to the dll calls.  But, since there is such a learning curve, am I missing something with the debug option?  Can I actually break into IDE debug mode in the middle of running the application like she's suggesting?  Personally, seeing that the IDE is 32-bit and the application is 64-bit I don't see how but I could be completely misunderstanding that part of it.

Oh, two other things.  I did recreate the exe using PB 2019 R3 and used the runtimes from the runtime packager and got basically the same result but pbshr.dll instead of pbshr190.dll and I'd be more than happy to include the .dbg trace file if anyone wants to page through 834,811 lines of code (which is just the open and close of the app).  I would strip away the meaningless parsing and whatnot of course.  Anyway, any help would be greatly appreciated because I am at a complete loss!!  We have some clients that are wanting to merge over to a 100% 64-bit application and this is now the hold up.

Aimee

  1. 64-bit
  2. Memory Leak
Database conversion
Convert Hex to Base64 String
Responses (2)
John Fauss
John Fauss Accepted Answer Pending Moderation
  1. Wednesday, 15 December 2021 04:23 AM UTC
  2. PowerBuilder
  3. # 1

Greetings, Aimee -

Regrettably, I don't have any definitive answers for you, but I do have some things I think you should know about:

1. I see in your post you mention the COBOL-interfacing DLL is indeed 64-bit. That's good. If/when you run the app from the PB IDE, it is a 32-bit app and it therefore must be able to access/use a 32-bit version of that DLL. When deployed as a 64-bit app, the app must be able to access/use a 64-bit version of the DLL.

2. Regardless of what your SysAdmin believes he/she knows, it is NOT currently possible to use a debugger when the PB app is 64-bit. A 64-bit PB app is compiled is PB psuedo-code (residing in PBD's) only, there is currently no option for producing a PB app in 64-bit machine code (in DLL's) - and, as you know, today's debugger in PB is 32-bit only. If you wish to enlighten your SysAdmin, explain that the statements in a PB app that has been compiled to psuedo-code get interpreted and executed at runtime by the PB virtual machine (PBVM), so it is not possible to set watch/stop points using a conventional C/C++ debugger.

3. Regarding your COBOL-interfacing DLL, you should be aware that the argument passing protocol (the in-memory size of some datatypes and the internal alignment of structure members, for example) may differ between 32-bit and 64-bit. Depending on the datatypes of the values passed into and out of the COBOL-interfacing DLL and whether the arguments are passed by value or by reference, they can potentially be different than in 32-bit. This is one reason Appeon provides a 64-bit migration guide, so I recommend you review it.

4. The PB Environment object contains a property named ProcessBitness, which will be either 32 or 64. You can use this to test and code for bitness-dependent conditions, if need be.

5. I echo Armeen's suggestion that you migrate to a newer version of the PFC. From the info you provided, it appears you may have a "corporate" set of libraries/objects between the base PFCxxxxx and the extension PFExxxxx. If so, that will complicate the migration, but if you're going to be producing 64-bit PB applications based on the PFC framework, you should a version that supports 64-bit. If you do have a corporate layer (PFWxxxxx?), depending on what is added/changed/overridden in it, you may be able to either eliminate it or move the changes to the PFE-layer.

Please continue to post additional questions on this forum (separate threads for each unique topic/issue, please)! There are many experienced and knowledgeable people here that are willing to help.

Best regards, John

 

Comment
Aimee Stephens
  1. Aimee Stephens
  2. Wednesday, 15 December 2021 20:27 PM UTC
Thank you, John!

The framework is quite large and I'm the lone person in charge of maintaining it. I tried for years to convince the bosses that we needed to migrate from PB7 but they wanted to wait until PB was a full 64-bit application and now here I am way behind and have obviously missed quite a few steps in my rush to get the 64-bit exe created. I'm still very confused as to why it worked the first time and now it doesn't. Also, the framework is used to create 4 different other applications and they're all able to exit cleanly. Just this one is having issues. I'm going to try the suggestion you and Armeen have made.



Aimee
  1. Helpful
There are no comments made yet.
Armeen Mazda @Appeon
Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 15 December 2021 00:30 AM UTC
  2. PowerBuilder
  3. # 2

I'll let other people with real hands-on experience chime in how to debug, but just wanted to make sure you were aware that adding 64-bit debugger is on our roadmap for PB 2022.

Also, couple things to consider:

1. Are you certain the issue is in the PB app rather than the COBOL DLLs?

2. Did you perform a proper migration to 64-bit?  Simply recompiling a 32-bit app is likely to cause problems.

Comment
Aimee Stephens
  1. Aimee Stephens
  2. Wednesday, 15 December 2021 01:08 AM UTC
Thank you so much for your quick response! A 64-bit debugger will be wonderful!



1. I am not certain whatsoever. Our system admin is the one who is adamant that there's a memory leak from the PB application. Here's the end of the .dbg trace file:



End class function +DESTROY for class PFW_N_CST_APPMANAGER, lib entry PFW_N_CST_APPMANAGER

End class function +DESTROY for class N_CST_APPMANAGER, lib entry N_CST_APPMANAGER

End class function +DESTROY for class N_CST_FUNDS_APPMANAGER, lib entry N_CST_FUNDS_APPMANAGER

Executing object function +DESTROY for class ENVIRONMENT, lib entry _TYPEDEF

End object function +DESTROY for class ENVIRONMENT, lib entry _TYPEDEF

It appears to me that everything that I've requested to be destroyed has been destroyed. She says something about closing the DLLs but I never open any DLLs so how am I supposed to close them? Our application was built using the PFC framework back in 2000 and we had someone from Sybase come in and help us create our framework. The open and close code hasn't really changed much since. Create the application manager, security object, etc then destroy them upon close.



Regarding COBOL DLLs, after I recreated the exe using PB 2019 R3 and performing the debug I got this:

'fundgui.exe': Loaded 'C:\netexpress51\Base\Bin\Win64\cob32api.dll', Cannot find or open the PDB file

The thread 'Win64 Thread' (0x2a98) has exited with code 0 (0x0).

Unhandled exception at 0x655e7cb6 in fundgui.exe: 0xC00000005: Access violation reading location 0x00007fffff309d008.



2. I do not believe I went through any 64-bit migration steps - didn't know I needed to - but I possibly could have seeing it's been a year ago. I'll look into that first thing in the morning. However, what confuses me the most is that when I first performed the migration and created the 64-bit exe it worked fine. And now just simply performing the open and immediately exiting we get the error. Of course, it is a different PB release/build and I don't know if that affected anything.



Thank you again!
  1. Helpful
Armeen Mazda @Appeon
  1. Armeen Mazda @Appeon
  2. Wednesday, 15 December 2021 01:14 AM UTC
Is cob32api.dll a 64-bit DLL?

Have you tried running the PB app using "Run as Administrator" option?

Are you using latest PFC libraries? Changes were made to support 64-bit. https://github.com/OpenSourcePFCLibraries/2019

I don't know exactly what's causing it, but these are some possible things to consider.

  1. Helpful 1
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.
We use cookies which are necessary for the proper functioning of our websites. We also use cookies to analyze our traffic, improve your experience and provide social media features. If you continue to use this site, you consent to our use of cookies.