PB crash after call to pfc_print 1

[Statey603]

We have an issue with PB crashing after a call to pfc_print [dw_1.event pfc_print()]. When the crash occurs we receive the following msg: PowerBuilder encountered a problem and needs to close]
...more info...Error signature: AppName: pb110.exe, ModName: pbshr110.dll, Ver: 11.0.0.6525, Offset 000ec502.
This issue just came to our attention. The code has not been modified in a few years however, we are not sure if it is a new issue or one that was just discovered. The crash does not happen every time we print, but quite regularly making me think it is some sort of memory related issue. I have tried a debug trace [appname.exe /pbdebug], but am not sure how to interpret. It ends with some destroy calls.
End class function __DESTROY_OBJECT for class DWOBJECT, lib entry _TYPEDEF
End class function +DESTROY for class DWOBJECT, lib entry _TYPEDEF
I appreciate any suggestions on how to troubleshoot.

 

[mbalent]

Does this app run on a single pc? multiple? Does it happen for everyone who runs it?

Matt

"Nature forges everything on the anvil of time"

http://www.anvil-of-time.com

 

[Statey603]

Hi Matt,
This issue is happening on all PCs and users that we have tested.
fyi....We have not changed PowerBuilder versions and/or PB runtime files distributed with our build.

Further investigation shows that it happens during screen Close but only after the screen receives focus back from the pfc_print dialog. If the print dialog is not used, then the crash does not occur. The user does not actually have to print, just click the print button which launches pfc_print. I am not sure if the printer driver has changed, but can tell you that it happens with different printers.

 

[mbalent]

Have you tried making a 'new build'? By this I mean recompiling and re-distributing the application files and the run time dlls.

Matt

"Nature forges everything on the anvil of time"

http://www.anvil-of-time.com

 

[Statey603]

Hey Matt,

Yes, I have tried recompiling / optimizing the objects and even tried getting all the distributed runtime files from our previous build.
We detected the problem during our current regression testing where we print a number of reports, then run some automated ROBOT scripts to populate data, then print the reports again to verify counts, etc. The problem arises on the 3rd or 4th pre-ROBOT report print so we cannot get through this stage. We did not see this during our last regression test in OCT. So, either the problem is new or possibly a memory related issue just surfacing.

The current situation is that now it is easy to reproduce and always happens during a screen close right after pfc_print. One thing that I do not have control of are driv ers and OS updates. Can pfc_print be affected by printer driver or windows XP updates?

Thanks,
Bill

 

[Statey603]

I have found a ciuple links (below) for similar reports issue. One references an EBF fix. I am going to try to locate that.

http://nntp-archive.sybase.com/nntp...le/<367_sNErZbLc#GA.293@forums.powersoft.com>

https://groups.google.com/forum/?fromgroups#!topic/sybase.public.powerbuilder.general/XOuaDxe0icc

my fingers are crossed.

- Bill

 

[Statey603]

Well the info found at that link did NOT fix the problem so I am open to other suggestions.
- Bill

 

[mbalent]

The pfc_print event on u_dw essentially calls the Print method on the datawindow in the form: this.Print(true,true). The first parameter is whether to show the cancel dialog (true is default behavior). The second is whether to show the system print dialog (in this case false is the default).

So one question is do you encounter these dialog boxes prior to the system crash?

If possible, override this code in the window you are having the issue and just issue the call yourself: this.print(true,false) <first with defaults, then again with true,true like the pfc does.

Matt

"Nature forges everything on the anvil of time"

http://www.anvil-of-time.com

 

[Statey603]

Matt,

You are a genius. I tried dw.print(true, true) and dw.print(true,false) instead of dw.pfc_print() and in both cases did not get the crash. Since the users need to be able to select a printer via print dialog, I will use print(true,true) as my workaround to pfc_print(). I need to test this out more but preliminary testing is very encouraging (although a bit disurbing sine we have ptfc_print in many places). However, the crash only seems to happen when users execute print multiple times from the same screen. Seems like something is compounding with pfc_print.

Would this indicate that pfc_print() might have a memory leak?

Thanks,
Bill

 

[Statey603]

Update.........

I created a new build with pfc_print() replaced with dw.print(true,true).

I created a few automated test scripts with Rational ROBOT to loop on launching and closing the print dialog. The pfc_print() implementation fails on the 2nd or 3rd pass. The print(true, true) implementation looped 50 times with no hiccups.

I am not sure what the specific cause for the crash is, however, this is a very reasonable workaround.

Thanks,
Bill

 

[mbalent]

Glad it worked

Matt

"Nature forges everything on the anvil of time"

http://www.anvil-of-time.com

 

[Topwiz]

Older versions of PFC used an external function in PBVM***.DLL which went away in newer versions of PowerBuilder. That code in the ancestor must be replaced with calls to the datawindow print function as mentioned earlier.

 

[lcombs1950]

I know this is probably too late, but, it's been a while since I have been on the forum. We have started having this problem with our application as well. After doing some research it would appear that it has something to do with Windows 7. Prior to our going to this we did not have this problem.

 

[Statey603]

Hi lcombs1950,
We actually encountered this on Windows XP machines. I am not sure how many places we call pfc_print() but we decided to only implement the workaround for instances that exhibit the problem and so far that is just 1 occurrence.
- Bill