1. Pete N
  2. PowerBuilder
  3. Saturday, 10 June 2023 15:08 PM UTC

Greetings PB Community. I'm a PowerBuilder novice who has inherited an app that's over 25 years old.

I'm looking for tips on debugging an app that I migrated from PB8 to PB2019 and on to PB2022. I do not believe the migrations have anything to do with my issue. The app crashes when it queries the database for a larger amount of data. It only sometimes does it on my development computer, while it always happens on the live environment, making it difficult to pinpoint what is going on. It's not really that much data- 11,520 rows with 3 columns. I overtest on my development computer with queries that contain 50,000 or more rows (it hangs for a few seconds, but doesn't crash the app). The query results are used to draw a graph within a tab control.

Here is what I've been able to gather:

  • A SELECTIONCHANGED event occurs on the tab control and some automatic cleanup occurs? 29 instances of the following is included in my .dbg file:
    Executing object function +DESTROY for class DWOBJECT, lib entry _TYPEDEF
    Executing instruction at line 2635
    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 2636
    End class function +DESTROY for class DWOBJECT, lib entry _TYPEDEF
  • If the app crashes, the .dbg file ends there
  • If the app doesn't crash it goes on to call the ACTIVATE event on the parent window
  • The following is a portion of the .dmp file:
    STACK_TEXT:  
    00000090`2c0f48d0 00007ff9`83b7c03a     : 00007ff9`82dfd558 0000027f`00001fa0 7fefffff`ffffffff 00000000`00000000 : KERNELBASE!RaiseException+0x69
    00000090`2c0f49b0 00007ff9`835089b5     : 000001c1`d0e8e3e0 00007ff9`840af5c4 00000000`00005fe6 00007ff9`00000001 : orageneric19!skgesigOSCrash+0x5a
    00000090`2c0f4ad0 00007ff9`83b7c38e     : 00007ff9`d3bb90d8 00000090`2c0f4640 00007ff9`d3bb238d 00000000`00000000 : orageneric19!kpeDbgProcessInit+0x1995
    00000090`2c0f4b70 00007ff9`e8eddd57     : 00000000`00000000 00007ff9`83b7c2f0 00000000`00000000 00007ff9`e8e00ddb : orageneric19!skgesigGetDetails+0x31e
    00000090`2c0f50e0 00007ff9`eb2ff5c8     : 00000000`0010000b 00007ff9`e8eddb70 00000090`2c0f5ac0 000004d0`fffffb30 : KERNELBASE!UnhandledExceptionFilter+0x1e7
    00000090`2c0f5200 00007ff9`eb2d0e20     : 00000090`2c0f5fb0 00007ff9`eb3a99a4 00000000`00000000 00000000`00000000 : ntdll!LdrpLogFatalUserCallbackException+0x98
    00000090`2c0f5340 00007ff9`eb2d23df     : 00007ff9`eb2d0e00 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!KiUserCallbackDispatcherHandler+0x20
    00000090`2c0f5380 00007ff9`eb2814a4     : 00000000`00000000 00000090`2c0f58f0 00000090`2c0f5fb0 00000000`00000000 : ntdll!RtlpExecuteHandlerForException+0xf
    00000090`2c0f53b0 00007ff9`eb2d0f0e     : 00000000`00000060 000001c1`ce0b0cc0 00000000`00000000 00007ff9`e8de40c4 : ntdll!RtlDispatchException+0x244
    00000090`2c0f5ac0 00000000`74fe5e43     : 000001c1`d44eeb80 00000000`00000000 000001c1`d3e30b00 00000000`00000000 : ntdll!KiUserExceptionDispatch+0x2e
    00000090`2c0f6270 00000000`74fe43a8     : 000001c1`d3e30b00 00000090`2c0f65c9 00000000`00000000 00000000`00000020 : pbdwe!dwSyntaxFree+0x25083
    00000090`2c0f62a0 00000000`74fe5762     : 00000200`00000007 00000000`00000000 00000090`2c0f65c9 00000000`00000000 : pbdwe!dwSyntaxFree+0x235e8
    00000090`2c0f63f0 00000000`74fc1e89     : 00000000`00000000 00000000`00000000 00000090`2c0f65c9 000001c1`d499300c : pbdwe!dwSyntaxFree+0x249a2
    00000090`2c0f6540 00000000`74d2d234     : 00000000`00000000 00000000`000014d3 000001c1`d4740890 00000000`75381b45 : pbdwe!dwSyntaxFree+0x10c9
    00000090`2c0f6620 00000000`74d2eff1     : 000001c1`d40cccdc 00000090`2c0f6770 00000000`000014d3 00000000`00000000 : pbdwe!dwCrosstabSortCmp+0x6864
    00000090`2c0f6670 00000000`74d2ceb0     : 000001c1`d40cccdc 00000000`00000000 000001c1`d3e1c9fc 000001c1`d40cccdc : pbdwe!dwCrosstabSortCmp+0x8621
    00000090`2c0f6830 00000000`74f19e0f     : 000001c1`d3e4408c 000001c1`d4347934 00000090`2c0f6929 00000000`00000000 : pbdwe!dwCrosstabSortCmp+0x64e0
    00000090`2c0f68d0 00000000`74f1e3c3     : 000001c1`d3e4408c 000001c1`d40cccdc 000001c1`d3e4408c 000001c1`d40cccdc : pbdwe!dwWinProcEdit+0x932f
    00000090`2c0f6990 00000000`74f12bf3     : 000001c1`d3e30e88 ffffffff`a0010b55 000001c1`d3e30e88 000001c1`d3e373e4 : pbdwe!dwWinProcEdit+0xd8e3
    00000090`2c0f6a20 00000000`74f12982     : 00000090`2c0f6bc0 000001c1`d4034060 00000000`00000000 000001c1`d3e30e88 : pbdwe!dwWinProcEdit+0x2113
    00000090`2c0f6a50 00000000`74d6911a     : 00000090`2c0f6bc0 00000000`7501d5f8 000001c1`d3e30e88 00000090`2c0f6bf0 : pbdwe!dwWinProcEdit+0x1ea2
    00000090`2c0f6ac0 00000000`74f3533f     : 00000000`00000000 000001c1`d3e30e88 00000000`0049414e 00000090`2c0f6bf0 : pbdwe!dwSyntaxFromDesc+0x1335a
    00000090`2c0f6af0 00000000`74ef985b     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : pbdwe!dwWinProcEdit+0x2485f
    00000090`2c0f6d20 00000000`74ef6b46     : 00000000`002a0b76 00000000`00000000 ffffffff`00000001 0001eb01`00000124 : pbdwe!dwWinProc+0x2e7b
    00000090`2c0f6fe0 00007ff9`ea84e858     : 00000000`00000001 00000000`00000000 00000000`80006010 00000000`00000000 : pbdwe!dwWinProc+0x166

As I stated, I'm just looking for some tips to get this figured out. If there is more info that I can provide or anything else I should be looking at or trying, please let me know. 

Thanks!

 

Accepted Answer
Pete N Accepted Answer Pending Moderation
  1. Tuesday, 20 June 2023 07:24 AM UTC
  2. PowerBuilder
  3. # Permalink

I have been able to narrow it down that when a Graph DataWindow retrieves between 8192 and 16000 rows, it will cause the application to crash. Any more or less than that, it's fine (there may be other ranges but I've gone up to 70,000 rows without issue). I put together a small app to demonstrate this and narrow it down to that specific range and filed a bug report:

https://www.appeon.com/standardsupport/track/view?id=10437

Since the same data runs fine in a tabular DataWindow, I'm pretty confident that this is some bug due to how graphs are drawn. But I've been wrong plenty of times before!

Thanks everyone for the tips!

Comment
  1. Pete N
  2. Tuesday, 20 June 2023 16:28 PM UTC
Miguel- yeah, this one was tricky to pinpoint, since a crash occurs within a range of retrieved rows (8192-16,000). But after running alot of tests and verifying it through a small test app, it weeded out the possibility of it being something that our much larger program was doing.
  1. Helpful 1
  1. Miguel Leeuwe
  2. Tuesday, 20 June 2023 16:54 PM UTC
Good to hear. Anyway, showing that many datapoints on a small graph, probably doesn't have any useable output? One of the problems with grapsh is that initially they look lovely, but as data starts to grow, they become less and less readable. What you then can do, is add scrolling, zoom, scale etc.
  1. Helpful
  1. Pete N
  2. Tuesday, 20 June 2023 17:38 PM UTC
Yeah, I wish I could go without some of the data. The problem is sometimes we have invalid data- which is shown as a point that is outside the normal range. This app updates in near real-time and if it were to alternate between different datasets, the graphs would change drastically from one scan to the next. Our customers would question why it is doing that and would have reduced confidence in the integrity of the data.
  1. Helpful
There are no comments made yet.
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Friday, 16 June 2023 07:06 AM UTC
  2. PowerBuilder
  3. # 1

What you could try is to delete the graph control from your datawindow (dw) and then create a fresh new extra datawindow of "type graph" and put it in a dw control somewhere next to the others.

Feed it with the same data and hopefully that deals a little bit better (more stable) if there are a lot of rows.

No guarantee, but maybe it works better.

regards

Comment
  1. Pete N
  2. Sunday, 18 June 2023 03:38 AM UTC
Thanks Miguel. I tried that and unfortunately, same result.
  1. Helpful
There are no comments made yet.
Pete N Accepted Answer Pending Moderation
  1. Thursday, 15 June 2023 21:40 PM UTC
  2. PowerBuilder
  3. # 2

Edit: It does not seem this is fixed.

Update with potential solution/sanity check as I was able to get it to crash in my test environment enough to pinpoint the potentially problematic code:

IF NOT IsNull(myVar) AND Len(myVar) > 3 THEN someVar = myVar

According to https://stackoverflow.com/questions/9580419/powerbuilder-null-and-empty-variable, Powerbuilder "unlike C language, PB is not making lazy evaluation, i.e it always evaluates all the parts of the condition and does not stop at the first false or true part"

So it seems that you should never evaluate IsNull and something else on the same variable at the same time. This bug has been in the app for many years and has probably been the culprit behind quite a few unexplained crashes that left nothing in the error log.

Correcting this code has resulted in the crashes to stop (for now), but I've made several fixes previously where it stopped happening and I thought I had fixed it. Keeping my fingers crossed.

Comment
  1. Miguel Leeuwe
  2. Thursday, 15 June 2023 22:40 PM UTC
Thanks for sharing!

Yes, the Isnull() has its little twists. Like for example if one value in an IF statement is null, it will immediately go to the ELSE part,. You don't know how many IF IsNull(ls_string) then ls_string = "" there is in my code before doing any other IF statements.

regards.
  1. Helpful
  1. Arnd Schmidt
  2. Thursday, 15 June 2023 23:13 PM UTC
Can you explain what the problem with that line of code should be?

"IF NOT IsNull(myVar) AND Len(myVar) > 3 THEN"

I do not understand why this should lead to a GPF :-(

For sure you do not need the "NOT IsNull(myVar) " because of the AND Operator.

In such a case I always use only an "IF Len(myVar) > 3 THEN" Statement that evaluates only to TRUE if myVar is not NOT NULL and its length is > 3.



regards

Arnd
  1. Helpful
  1. Pete N
  2. Thursday, 15 June 2023 23:45 PM UTC
Arnd- I just went back and tried doing what you suggest, which worked. I then reverted it back and it's not crashing again. This is pretty bizarre and it seems like I'm back to square one.
  1. Helpful
There are no comments made yet.
mike S Accepted Answer Pending Moderation
  1. Sunday, 11 June 2023 16:09 PM UTC
  2. PowerBuilder
  3. # 3

"The query results are used to draw a graph within a tab control."

is the graph a graph datawindow, or a graph control?

If you disable the graph portion, do you still have the problem?

 

In some versions of PB (starting around 12) , i had major issues with graph datawindows causing the application to crash.  These issues were cleared up in the later releases (pb 17R3 time frame i believe).  In most cases it seemed to occur when the data was coming slowly back from the database.

 

 

Comment
  1. Miguel Leeuwe
  2. Monday, 12 June 2023 17:01 PM UTC
Great stuff Mike!
  1. Helpful
  1. Miguel Leeuwe
  2. Monday, 12 June 2023 17:05 PM UTC
Though... if the OP has migrated to 2019 and then to 2022, the fix should have been included in 2022, if fixed somewhere in 2019 ?
  1. Helpful
  1. Pete N
  2. Wednesday, 14 June 2023 13:47 PM UTC
Hey Mike-

I did try the 2022R2 BETA and my graphs were really messed up. The graph properties (line colors, symbols, thickness, etc) are set via script and it seems like none of them were being applied. I didn't dig too deep into that since the graph was still crashing the app, anyways.
  1. Helpful
There are no comments made yet.
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Sunday, 11 June 2023 03:57 AM UTC
  2. PowerBuilder
  3. # 4

Hi,

Apart from very good advice given by others, I'm thinking maybe some datawindow or datastore is being destroyed in the "cleanup" code. I that then still is being used somewhere after the cleanup, that would crash you application.

As a test, try comment out all of the cleanup code (temporarily) and see what happens.

Also, what's being used to show your "graph"? Is it a Powerbuilder graph datawindow, or maybe some third party control?

regards.

Comment
  1. Pete N
  2. Monday, 12 June 2023 13:48 PM UTC
Hi Miguel-

The ShareData() function is called during a timer event, which itself is called when the app updates with the latest data, or when the user changes tabs (each tab has the two datawindows mentioned previously). The control is not set to Render3D. These are line graphs with no symbols. Up to 8 lines are drawn on each graph and the crashes occur when 8 lines are being displayed. In this case it's 8 lines with one data point per minute over one day (8 x 60 x 24 = 11,520).

There is a ShareDataOff() that is called during the SelectionChanged event (tab event).

I commented back in the sharedata and deleted the graph. The tab loads quickly without issue.
  1. Helpful
  1. Miguel Leeuwe
  2. Monday, 12 June 2023 14:20 PM UTC
Hi,

I think it would be recommendable to call ShareDataOff() right before calling ShareData(). I'm not sure if that's going to help, but it won't do any harm.

Maybe it's just too much data for the graph?
  1. Helpful 1
  1. Pete N
  2. Monday, 12 June 2023 18:57 PM UTC
Thanks Miguel. I tried that and still got the same result.

I agree that it's probably too much data for the graph, which is unfortunate. Thanks for your help.
  1. Helpful
There are no comments made yet.
Roland Smith Accepted Answer Pending Moderation
  1. Sunday, 11 June 2023 01:46 AM UTC
  2. PowerBuilder
  3. # 5

Some Windows API functions that have by reference string arguments also have a number argument that is the length of the pre-allocated string. Some functions expect this to be the number of characters and some the number of bytes. You should review all external functions to make sure they are defined and called correctly.

PB 2022 is more particular about the data types. Where previous versions worked with the wrong datatype, PB 2022 might abort. Use this chart to choose the correct data types.

https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types

Many API functions have names ending with A or W. A is the Ansi version and W is the Unicode version. The PB migration process might add ;Ansi to your declaration. I would remove that and switch to the W version.

Comment
  1. Pete N
  2. Sunday, 11 June 2023 02:31 AM UTC
Thank you Roland. This app does not make any external function calls. It did previously to play a sound, but I replaced it with Beep(1), which had the same effect.
  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Saturday, 10 June 2023 18:27 PM UTC
  2. PowerBuilder
  3. # 6

Hi Pete;

  I suspect that the App migration is the cause of your stability issues. I say that because in PB version 8.x, the IDE & Apps were single byte ANSI based. Starting in PB version 10.x, Sybase moved PB to be double-byte Unicode based for both the IDE & PB App runtimes. That change alone could have a huge impact on your app depending on what it was coded like.

  The next migration issue for stability is moving from a very old C++ compiler in PB version 8.x to PB 2022 which uses C++ version 2019. Another major change that again depending on how your app was coded originally, code mean some more refactoring may still need to be done.

   Another stability issue could be trying to use an old outdated DB driver. Since PB version 8.x, Sybase updated most DB drivers for the supported DBMS. If an incomparable DB driver is still being used, it could crash & take the PB IDE and/or App(s) down with it.

   The next area to look at is the newer Windows O/S's which may have introduced some hardships for your app based on its original coding approach. Again, some refactoring might be necessary from the perspective. 

   If your App(s) use any 3rd party controls, DLLs, OCX, OLE, etc external objects. They might need updating to be O/S, Unicode, bitness, etc compliant.

  If your PB App(s) make direct external calls to the O/S itself, these items may also need refactoring.

FYI: https://docs.appeon.com/pb/upgrading_pb_apps/index.html

  Also, if your apps use the PFC framework, they will also require you to update the framework to match your PB version, as follows: https://github.com/OpenSourcePFCLibraries

  Because of all these potential refactorings required, you might find it more expediant with your limited PB knowledge to use an Appeon consulting partner which has extensive PB experience in migrations. 

FYI: https://www.appeon.com/consultants/consulting-partners

HTH

Regards ... Chris 

   

Comment
  1. Pete N
  2. Sunday, 11 June 2023 16:22 PM UTC
Thanks Chris, and thank you for all of your replies on other topics as they have helped me greatly over the past year while working on this app. I have added some replies to Miguel in another thread that provides some more info. Feel free to chime in if there's anything else you think I should be looking at.
  1. Helpful 1
  1. Chris Pollach @Appeon
  2. Friday, 16 June 2023 14:01 PM UTC
You are most welcome! ;-)
  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.