Questions? Feedback?powered byOlark live chat software
Bug 3720

Application process runs for two and a half hours then abruptly terminates with a fatal Windows error 06 December, 2019

yakov werde
29 November, 2019
Product: PowerBuilder Category: DataWindow
Version: 2017 R3 Publishing: Public
Status: Verifying Priority: P2
Classification: Resolution:
Ken Guo 06 December, 2019
Hi Yakov,

Thanks for your feedback. Please follow this issue and check whether this issue is totally resolved. 
Thanks in advance.

Regards,
Ken
yakov werde 05 December, 2019
(In reply to Ken Guo from comment #10)
Hi Yakov,

We can’t find out the root cause of it from the source object you provided.
Currently we can only suspect that it might be related to the DataStore. I
suggest you modify you code according to the following rules:
1. Execute datastore.resetupdate() before all datastore.retrieve() and
datastore.reset().
2. Check all DataStore and see if there are any destroy datastore statements
lost.

If the issue still exists, could you please provide a small reproducible
case for us so that we could analyze and debug it locally?


Regards,
Ken
After laborious code inspection, and refactoring and testing we discovered that 1. Execute datastore.resetupdate() before all datastore.retrieve() and datastore.reset(). Did avoid the fault and allow the process to complete. We were able to run the process several time to completion Thank you
Ken Guo 02 December, 2019
Hi Yakov,

We can’t find out the root cause of it from the source object you provided. Currently we can only suspect that it might be related to the DataStore. I suggest you modify you code according to the following rules:
1. Execute datastore.resetupdate() before all datastore.retrieve() and datastore.reset().
2. Check all DataStore and see if there are any destroy datastore statements lost.

If the issue still exists, could you please provide a small reproducible case for us so that we could analyze and debug it locally?


Regards,
Ken
Chris Pollach 29 November, 2019
    Yes, the "UseHwnd=no" setting will work in the PB IDE as well as long as you update that parameter in the *working* PB.INI file. Normally found in... 
"C:\Users\<yourLogin>\AppData\Local\Appeon\PowerBuilder 19.0".

   Good idea on the DS/DWO refresh at the end of the usages loop.
yakov werde 29 November, 2019
(In reply to Chris Pollach from comment #6)
Hi Yakov;

  Thank you for confirming that this happens in both the 32bit and 64bit
realm. Also for attaching the SRU code!

  I will now transfer this ticket over to the main Support / Engineering
Team for their review.

BTW: Did you happen to monitor the amount of consumed memory for this App in
Task Manager just before the App's crash?

Regards ... Chris
I asked for my team member to do a test run with TaskManager active and process memory display I also asked for a test run with a PB.INI [DataStore Behavior] UseHwnd=no (Question - when running from IDE will this setting will go in the IDE's PB.INI ? ) Lastly I asked from a run with code modified to DW.Reset( ) / Destroy / Create etc. At the bottom of the loop. But since it's a last step action, dev's are reluctant to do the experiment. I
yakov werde 29 November, 2019
(In reply to Chris Pollach from comment #6)
Hi Yakov;

  Thank you for confirming that this happens in both the 32bit and 64bit
realm. Also for attaching the SRU code!

  I will now transfer this ticket over to the main Support / Engineering
Team for their review.

BTW: Did you happen to monitor the amount of consumed memory for this App in
Task Manager just before the App's crash?

Regards ... Chris
I asked for my team member to do a test run with TaskManager active and process memory display I also asked for a test run with a PB.INI [DataStore Behavior] UseHwnd=no (Question - when running from IDE will this setting will go in the IDE's PB.INI ? ) Lastly I asked from a run with code modified to DW.Reset( ) / Destroy / Create etc. At the bottom of the loop. But since it's a last step action, dev's are reluctant to do the experiment. I
Chris Pollach 29 November, 2019
Hi Yakov;

  Thank you for confirming that this happens in both the 32bit and 64bit realm. Also for attaching the SRU code!

  I will now transfer this ticket over to the main Support / Engineering Team for their review.

BTW: Did you happen to monitor the amount of consumed memory for this App in Task Manager just before the App's crash?

Regards ... Chris
yakov werde 29 November, 2019
uo_prepare_grpay_report.sru (778KB)

this is the original
yakov werde 29 November, 2019
uo_prepare_grpay_report_new.sru (1566KB)

(In reply to yakov werde from comment #3)
(In reply to Chris Pollach from comment #2)
Hi Yakov;

  Is this a 64bit PB App?

Also, are you still going to attach the various UO's source to this ticket?

Regards ... Chris
Hi Chris Thanks for asking: This issue is present in BOTH 32 and 64 bit.
yakov werde 29 November, 2019
(In reply to Chris Pollach from comment #2)
Hi Yakov;

  Is this a 64bit PB App?

Also, are you still going to attach the various UO's source to this ticket?

Regards ... Chris
Hi Chris Thanks for asking: This issue is present in BOTH 32 and 64 bit.
Chris Pollach 29 November, 2019
Hi Yakov;

  Is this a 64bit PB App?

Also, are you still going to attach the various UO's source to this ticket?

Regards ... Chris
yakov werde 29 November, 2019
DWfunctionGPF.png (169KB)

We have several major report and update processes that run at a big data (large) customer installation which fatally terminates during processing. Affected process run for lengthy time duration (~2.5 hrs) after which the sudden termination occurs.  The termination does not always occur at the same point in processing, but always after lengthy processing and always in a processing loop.

The common code pattern among all the failure points is Nested For Next Looping within which are DataWindow InsertRow(0) and SetItem( ) function calls

We believe this issue to be related to these similar issues which are due to acknowledged PowerBuilder runtime flaws
https://community.appeon.com/index.php/qna/q-a/huge-showstopper-memory-leak-bug-in-pb-2017-build-1681
https://www.appeon.com/standardsupport/search/view?id=535
https://www.appeon.com/standardsupport/search/view?id=544

The issue has been tested and fails using all current PB 2017 release runtimes (base R2 & R3) as well as the PB 2019   on Windows10 and Windows Server 2016.  It occurs when run as EXE and from the IDE

Please find attached one of several code objects (uo_prepare_grpay_report) in whose functions the termination occurs.  The termination can occur in any of the highlighted routines.

We attempted one code fix (shown in uo_prepare_grpay_report_new) by changing transaction scope.  This change failed to solve the issue.  You can see the changes we made by comparing the code objects in a DIFF utility.  

To date. we are unable to find a fix or work-around for this very high priority customer issue.  
Our expectation is that Appeon will repair known issues in datawindow runtime code which are suspect in this abrupt termination issue

Please advise if a runtime fix can be made available
OS:
Windows 10 
Platform:
All 
Database Type:
Microsoft SQL Server 
Database Version:
2017