1. Stefan Malkwitz
  2. PowerBuilder
  3. Thursday, 7 May 2020 11:20 AM UTC

Hello,

We have had some errors since the last update to PB2019r2 2328.
The program crashes from time to time. On the customer computer and also on the development computers, so I think its not computer related.
Someone has a good idea what we can try there?

 

thx Stefan Malkwitz 

 

The Last 10 Rows in the Trace Log just before the crash
-------------------------------------------------------------------------------
Executing instruction at line 10
Executing instruction at line 15
End event +DESTRUCTOR for class U_TP_XPLR_VIEWPAGE_ITEM, lib entry U_TP_XPLR_VIEWPAGE_ITEM
Executing object function +DESTROY for class DWOBJECT, lib entry _TYPEDEF
Executing instruction at line 2586
Executing object function __DESTROY_OBJECT for class DWOBJECT, lib entry _TYPEDEF
Executing system dll function
End class function __DESTROY_OBJECT for class DWOBJECT, lib entry _TYPEDEF
Executing instruction at line 2587
End class function +DESTROY for class DWOBJECT, lib entry _TYPEDEF
-------------------------------------------------------------------------------

 

Windows Crash Dialog:
-------------------------------------------------------------------------------
Problemsignatur:
Problemereignisname: APPCRASH
Anwendungsname: PB190.EXE
Anwendungsversion: 19.1.0.2328
Anwendungszeitstempel: 5e99c41e
Fehlermodulname: KERNELBASE.dll
Fehlermodulversion: 6.3.9600.19425
Fehlermodulzeitstempel: 5d26ae6e
Ausnahmecode: 4000001f
Ausnahmeoffset: 00034e28
Betriebsystemversion: 6.3.9600.2.0.0.272.7
Gebietsschema-ID: 1031
Zusatzinformation 1: 5ebb
Zusatzinformation 2: 5ebbf16b98c1a5270494093f5b2f129a
Zusatzinformation 3: c5d1
Zusatzinformation 4: c5d1c2ea6215d70fd58d748ddd652931

Lesen Sie unsere Datenschutzbestimmungen online:
http://go.microsoft.com/fwlink/?linkid=280262

Wenn die Onlinedatenschutzbestimmungen nicht verfügbar sind, lesen Sie unsere Datenschutzbestimmungen offline:
C:\Windows\system32\de-DE\erofflps.txt
-------------------------------------------------------------------------------

Malcolm Kenneth McCaffery Accepted Answer Pending Moderation
  1. Tuesday, 23 March 2021 01:53 AM UTC
  2. PowerBuilder
  3. # 1

I had the same issue but with PowerBuilder runtime 10.0.1.5502. Issue did not occur in Windows 7 x64, only Windows 10 x64.

I am not a PowerBuilder developer and didn't have access to the application code or PowerBuilder for testing, was just debugging the app.

Putting this info out there if it helps anyone ... From what I can see it is a problem with PowerBuilder runtime. The only way I could fix it is to patch the runtime:

1) It seems a windows message WM_GETOBJECT (0x3D) is being sent to all the message handlers for various controls in pbvm100.dll. This message was not being sent on my Windows 7 machines. The handler for these functions triggers code to load pbacc100.dll. On Windows 7 this function never gets hit and no attempt is ever made to load pbacc100.dll.

I patched pbvm100.dll to avoid hitting this code to load pbacc100.dll to match Win7 behavior.

2) In pbdwe100.dll there is a function seems to go through a linked list using pbshr100!shlist_get_first and  pbshr100!shlist_get_next and then calls a virtual function based on the result of these functions. When the app crashes it is jumping to a location without valid code (full of 0s) and eventually leads to access violation crash. Seems to be related to a data window. 

Patching pbdwe100.dll to check the target is valid before jumping stops the crash.

While this resolves the issue would be nice to have an official solution.

To be sure the same issue though would have to check with a memory dump. I found the easiest way to diagnose issue was to create a time travel trace. 

Time Travel Debugging - Record a trace - Windows drivers | Microsoft Docs

Although PowerBuilder app didn't work if launched directly from TTD tool, so I had to launch app first then attach to it by process id.

However working out the cause via this method does require good knowledge of WinDbg use and Windows APIs. 

 

 

Comment
There are no comments made yet.
Ken Guo @Appeon Accepted Answer Pending Moderation
  1. Thursday, 15 October 2020 07:52 AM UTC
  2. PowerBuilder
  3. # 2

Hi Stefan,

We take this crash issue very seriously. However, it is very hard for us to find out the root cause of it from the event or log you provided.

Could you please further locate which line of code is causing the crash via gradually commenting out a part of code?
It would be much helpful if you could provide a small reproducible case for us for further analysis.
If you can’t provide a small case for us, it is suggested you provide a machine that can reproduce it and with the remote tool installed (e.g., TeamViewer) for us so that we could remotely debug it.

BTW, to better track and handle this issue, please submit a bug to our support ticketing system (https://www.appeon.com/standardsupport/newbug). Thanks in advance.


Regards,
Ken

Comment
There are no comments made yet.
shai hadashi Accepted Answer Pending Moderation
  1. Tuesday, 13 October 2020 13:18 PM UTC
  2. PowerBuilder
  3. # 3

Hi, 

 

I have the similar problem with similar debug log and Windows crash log.

 

Any suggestions?

 

 

thx Daniel

 

Daniel, did you figure out the Runtime crash the seems to do with Garbage Collection and Destroy of the Datawindow Object?

 

Thanks,

 

Shai

Comment
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Friday, 19 June 2020 19:46 PM UTC
  2. PowerBuilder
  3. # 4

Hi Matthew;

   Could this be the issue ...

Regards ... Chris

Comment
There are no comments made yet.
Matthew Caffrey Accepted Answer Pending Moderation
  1. Tuesday, 16 June 2020 21:22 PM UTC
  2. PowerBuilder
  3. # 5

In our situation, we are calling the CloseTab function, which in turn destroys a bunch of nested objects, finishing up with same DESTROY entries in the debugger.

 

But what is particularly interesting, is that like OP (Stefan Malkwitz), I am seeing a really unusually high line number in the debug file.    Line 2332.

Up until that point, the highest line number anywhere in the debug file was line 120, and now it jumps to line 2332?  That seems odd.

 

I also think it is interesting that at least 3 people are reporting this error now, all with different versions of PowerBuilder.

 

 

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

            Executing instruction at line 2332

            Executing object function __DESTROY_OBJECT for class DWOBJECT, lib entry _TYPEDEF

              Executing system dll function

            End class function __DESTROY_OBJECT for class DWOBJECT, lib entry _TYPEDEF

          End class function +DESTROY for class DWOBJECT, lib entry _TYPEDEF

Comment
There are no comments made yet.
Matthew Caffrey Accepted Answer Pending Moderation
  1. Tuesday, 16 June 2020 21:02 PM UTC
  2. PowerBuilder
  3. # 6

Hi, my client runs a very old verison of PowerBuilder (version 10!), and we were getting this identical error.

 

Symptoms in common:
1) Same last line in the debugger:
End class function +DESTROY for class DWOBJECT, lib entry _TYPEDEF

2) Same error in the windows event log:

KERNELBASE.dll

3) And only started happening in the last few months of THIS YEAR.

 

Some people's machines get the error regularly, other people's machines never get it at all, so there seems to be a connection between other software installed on the machine and the crash.

 

Chris - were you suggesting that we SHOULD use GarbageCollect, or should not?  Because believe we aren't explicitly calling it, but I'd be happy to do so!

-Matthew Caffrey

matthew.caffrey@sapiens.com

 

Comment
  1. Matthew Caffrey
  2. Friday, 19 June 2020 19:25 PM UTC
Yep, using Oracle 12 32 bit client and ORA DBMS against our Oracle 12c.



So far everything is passing testing except for this particular call.



PB2019R2 gives an error that PB10 does not give:

"ORA-24358: OCIBindObject not invoked for a Object type or Reference."



This is how the location external function is defined in our transaction object:



subroutine prc_online_cov_save &

(string n_agre_id, &

string s_agre_prd_eff_dt, &

string s_agre_prem_prd_eff_dt [], &

string s_prem_typ_cd[], &

string s_stt_cd [], &

string n_lgl_enty_id_ptcp_busn_ins [], &

string n_risk_id [], &

string s_cls_cd [], &

string s_cls_cd_sufx [], &

string s_rt_typ_cd [], &

string n_lgl_enty_id_cvrd [], &

string s_agre_cov_eff_dt [], &

string s_rt_cls_typ_cd [], &

string n_agre_cov_prem_dup_cov_no [], &

string s_pyrl_rpt_id [], &

string s_lob_cd [], &

string s_agre_cov_rn_ind [], &

string d_agre_cov_prem_bs_val [], &

string n_agre_cov_prem_bs_unt [], &

ref string d_agre_cov_prem_drv_mnl_prem_amt [], &

ref string d_agre_cov_prem_drv_min_prem_amt [], &

ref string d_agre_cov_prem_drv_rt [], &

string s_agre_cov_drv_end_dt [], &

ref string s_err_msg [], &

ref string n_return_cd, &

ref string s_plcy_cov_prem_void_ind [], &

string s_per_cpta_ovrrd_ind [], &

string s_reissue_pyrl) RPCFUNC ALIAS FOR "PKG_COV.PRC_ONLINE_COV_SAVE"



This is how it is defined in our package specs:



PROCEDURE prc_online_cov_save (

av_agre_id VARCHAR2,

av_agre_prd_eff_dt VARCHAR2,

av_prem_prd_eff_dt pkg_std.vchar80lst,

av_prem_typ_cd pkg_std.vchar80lst,

av_stt_cd pkg_std.vchar80lst,

av_lgl_enty_id_ptcp_busn_ins pkg_std.vchar80lst,

av_risk_id pkg_std.vchar80lst,

av_cls_cd pkg_std.vchar80lst,

av_cls_cd_sufx pkg_std.vchar80lst,

av_rt_typ_cd pkg_std.vchar80lst,

av_lgl_enty_id_cov pkg_std.vchar80lst,

av_cov_eff_dt pkg_std.vchar80lst,

av_rt_cls_typ_cd pkg_std.vchar80lst,

av_agre_cov_prem_dup_cov_no pkg_std.vchar80lst,

av_pyrl_rpt_id pkg_std.vchar80lst,

av_lob_cd pkg_std.vchar80lst,

av_rn_cov_ind pkg_std.vchar80lst,

av_cov_prem_bs_val pkg_std.vchar80lst,

av_cov_prem_bs_unt pkg_std.vchar80lst,

av_cov_prem_drv_mnl_prem_amt IN OUT pkg_std.vchar80lst,

av_cov_prem_drv_mnm_prem_amt IN OUT pkg_std.vchar80lst,

av_cov_prem_drv_rt IN OUT pkg_std.vchar80lst,

av_cov_end_dt pkg_std.vchar80lst,

av_err_msg IN OUT pkg_std.vchar250lst,

av_return_cd IN OUT VARCHAR2,

av_plcy_cov_prem_void_ind pkg_std.vchar80lst,

av_per_cpta_ovrrd_ind pkg_std.vchar80lst,

av_reissue_pyrl VARCHAR2 DEFAULT 'n');



I believe the issue is the reference variables, like this:

pkg_std.vchar250lst



Which are defined in another package like this:

TYPE Vchar250Lst IS TABLE OF VARCHAR2 (250)

INDEX BY BINARY_INTEGER;

  1. Helpful
  1. Matthew Caffrey
  2. Monday, 22 June 2020 16:32 PM UTC
I have a fix for my error that I wanted to post here so other developers could use it as a reference.



"ORA-24358: OCIBindObject not invoked for a Object type or Reference."

I found the answer in similar OCI error from earlier versions posted here:

http://www.dbainfo.net/wp-content/uploads/CR/pb_135.htm#CR678092



The error comes from the PowerBuilder/Oracle interface being confused by OVERLOADED PL/SQL procedures. When I changed the name of my procedure so it wasn't overloading a same-named procedure anymore, the error went away.



  1. Helpful
  1. Chris Pollach @Appeon
  2. Monday, 22 June 2020 16:40 PM UTC
Hi Matthew .. thanks you for posting back as to the error & your fix! :-)

Yes, overloaded Stored Functions and Stored Procedure calls are not supported by PB.
  1. Helpful
There are no comments made yet.
Daniel Maak Accepted Answer Pending Moderation
  1. Tuesday, 19 May 2020 13:12 PM UTC
  2. PowerBuilder
  3. # 7

so new news...

I was able to solve the problem partialy, this means the unexpected application shutdown isn't gone but it is more reproduceable now.

One problem that I solved was that in one Datawindow was a DataObject assign thats not exists. For PowerBuilder 2017R3 version is that no problem but the for 2019R2 the assigned DataObject in a datawindow has to be exists.

 

I will give an update, if I solve all my problems...

Comment
There are no comments made yet.
Daniel Maak Accepted Answer Pending Moderation
  1. Monday, 18 May 2020 10:17 AM UTC
  2. PowerBuilder
  3. # 8

Hi, 

 

I have the similar problem with similar debug log and Windows crash log.

 

Any suggestions?

 

 

thx Daniel

Comment
  1. Chris Pollach @Appeon
  2. Monday, 18 May 2020 14:14 PM UTC
Hi Guys.... Out of curiosity, do your PB Apps use the GarbageCollect() command?

Regards ... Chris
  1. Helpful
  1. Miguel Leeuwe
  2. Monday, 18 May 2020 14:22 PM UTC
"line 2587" ? hmmmm .... I'm not saying anything negative here, we also have scripts that large. Could it be related?
  1. Helpful
  1. Chris Pollach @Appeon
  2. Monday, 18 May 2020 15:11 PM UTC
Hi Miguel... It seems to be where the code is destroying DWs. I wonder if the apps use this code like I do in my frameworks.

DS.reset()

DS.dataobject = ""

Destroy (DS)



In the destruction event of my DC ancestors, I use ...

This.reset()

This.dataobject = ""



Note: you can also do the above for your DC's as well. This tends to really help the PBVM with resource clean-up.
  1. Helpful
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.