cancel
Showing results for 
Search instead for 
Did you mean: 

64 bit compiler woes

Former Member
0 Kudos

Colleagues,

I'm currently tasked with exploring 64bit deploy for a massive PowerBuilder app. I've currently hit the wall with an issue and am wondering if other's have had or are having a similar experience.

First an observation: Not having a 64 bit IDE is detrimental to productivity!  The only way to test an app in 64 bit is by doing a complete build.  In our case even the smallest change requires an over 90 min compile cycle.  Because of PBL interdependencies building a single PBD takes almost as long as a complete build.  This is similar to the PB .NET compile situation.

Now on to the issue:

One of the central application features is a window whose code size is well over 1.1meg, coupled with all the related objects it instantiates, we're talking about a massive memory load.  The window has (through v12.5) and continues to (in v12.6) compile and run correctly in the 32 bit environment

While most of the app is running fine, in 64bit deploy instantiating and rendering this massive window at runtime is failing miserably.  From the outside, it is throwing systems error in <<dw>>.object assignment statements on load. But on the inside - from the perspective of debug traces - things are worse.  Symptoms seems to indicate that the referenced datawindows are not present at runtime

Here is a side-by-side comparison of the affected area as seen in /debug traces

The 32bit version, shown on the right (12.5 & 12.6 are the same) creates 12 DWObjects in a row, including creating and calling global functions referenced in property expressions

Then it moves on to create other window controls

The 64 bit version creates 4 DWObjects and then moves on to window size setting activities.  Skipping entirely over creating dataobject and the other controls.  It really looks like the create sequence is messed up for this massive window.  I have not been able to isolate the issue and reproduce it in a small app.

I'm really at a loss what to do here.  I can't create a case yet because I can't reproduce this in a small app.

Any suggestions are appreciated

Yakov

One positive side note:  Although I have not seen this written, It seems to be clear that PBDs are bit size independent.  Once they are created they can be used for both 64 and 32 bit EXEs

Accepted Solutions (0)

Answers (5)

Answers (5)

Former Member
0 Kudos

i'm glad someone is pioneering the 64bit realm for us ... but, I feel your pain. 

Former Member
0 Kudos

Hi Chris,

I don't have pain nor is anyone suffering.  While I'm sure my sponsor is not pleased to have to expend extra effort to achieve their goal, I would not go so far as to use the term pain.  New major features are rarely perfect in the 1st round.  Please recall that it took quite a bit of effort for 32 bit machine code to be perfected.  Many still shy away from it - "just cause" it got a bad reputation in the beginning.

Yakov

Former Member
0 Kudos

Hi Yakov,

Your remarks could easily be applied to PB.Net but I'm afraid it wasn't afforded the same patience.

Mark

Former Member
0 Kudos

Hi Yakov;

    I'm not knocking it .. just sympathizing in having to go through all the idiosyncrasies on a new product when your under the gun to deliver. We have all been there and hopefully, you have an understanding IT manager.

Good luck!

Regards ... Chris

Former Member
0 Kudos

Last night I updated to EBF 4011 and ran the app without compiling in order to explore whether it was just a runtime issue.  Result: Same error.

Did a full deploy to 64 bit and ran the app.  Result:  Same error

Will have to speak to my management about opening a case

Former Member
0 Kudos

I see these all over the place.  I don't believe these have any bearing on the issue we are experiencing

arnd_schmidt
Active Contributor
0 Kudos

Yakov,

what is the reason for the "stack size changed during routine call"?

Former Member
0 Kudos

Hi Yakov;

=>  It really looks like the create sequence is messed up for this massive window.  I have not been able to isolate the issue and reproduce it in a small app.

I suspect that you are facing a 64bit compiler anomaly once a more complex component is in the picture. Unfortunately, this is a situation where SAP Engineering may need your application source in order to pin point the issue(s).

Regards ... Chris