Complied app hangs on Exit Function statement

[Schmidt]

I always check/test my idea in IDE before publishing something.

Well, I'm quite sure you didn't test this, before posting here:
"Speed is everything for this program. GoSub works faster."

Normal Sub-routines are much faster than GoSub-calls (native compiled).
https://www.vbforums.com/showthread....=1#post5519147

Olaf

[Nouyana]

Well, I'm quite sure you didn't test this, before posting here:
"Speed is everything for this program. GoSub works faster."

Normal Sub-routines are much faster than GoSub-calls (native compiled).
https://www.vbforums.com/showthread....=1#post5519147

Olaf

Be sure, I've tested it before use. As I said, I use P-Code for now because of many reasons. Usually in my apps, the P-Code works faster, because the msvbvm60.dll better than OS distributes tasks to threads. Now I decided to test it again, but I ran into a problem (my app hangs in Native Code).

Test results in P-Code are antithetic. And of course you shouldn't use calculations in such a tests. I would do it like that:

Option Explicit

Public Const ITERATIONS = 100000000

Private Declare Function _
   a2ku_apigettime Lib "winmm.dll" _
   Alias "timeGetTime" () As Long
Private Ingstartingtime As Long

Private i              As Long
Private ForNextTime    As Long
Private GoSubTime      As Long
Private PrivateSubTime As Long

Sub Main()
   
   TimerStart
   For i = 1& To ITERATIONS
   Next
   ForNextTime = TimerStop
   
   TimerStart
   For i = 1& To ITERATIONS
      GoSub GoSubRoutine
   Next
   GoSubTime = TimerStop - ForNextTime
   MsgBox "GoSubTime: " & GoSubTime
   
   TimerStart
   For i = 1& To ITERATIONS
      PrivateSubRoutine
   Next
   PrivateSubTime = TimerStop - ForNextTime
   MsgBox "PrivateSubTime: " & PrivateSubTime
   
   Exit Sub
   
GoSubRoutine:
   '
   Return
   
End Sub

Private Sub PrivateSubRoutine()
   '
End Sub

Private Sub TimerStart()
    Ingstartingtime = a2ku_apigettime()
End Sub
Private Function TimerStop() As Long
    TimerStop = a2ku_apigettime() - Ingstartingtime
End Function

[Schmidt]

Test results in P-Code are antithetic.

Yes, GoSub is faster in PCode - but you were the one looking for performance -
(trying to run this specific App native compiled).

And native-compiled - the elemination of GoSub (in favour of new SubRoutines),
would not only speedup your App, but probably solve the original "crash problem" as well.

Olaf

[Nouyana]

And native-compiled - the elemination of GoSub (in favour of new SubRoutines),
would not only speedup your App, but probably solve the original "crash problem" as well.Olaf

Maybe. I should research it. There are some other reasons (for me) for using P-CODE:
1. Sometimes I can just copy/paste a piece of code between VB6 and VBA. As you know VBA uses P-CODE.
2. When you have a deal with accounting, you are working with a lot of very similar (debt-credit), but, at the same time very different routines. So you should group it somehow in your project and documentation. Of course I use modules and normal sub-routines, but it's not enough. I use GoSub too. Just to simplify my project documentation. This is just another level of grouping.

[wqweto]

And native-compiled - the elemination of GoSub (in favour of new SubRoutines),
would not only speedup your App, but probably solve the original "crash problem" as well.

Btw, there is no problem with VB6 codegen on With MyUdtArray(5) ... End With blocks with any GoSub/GoTo shenanigans one might use.

004019A5 8B EC                mov         ebp,esp  
004019A7 83 EC 0C             sub         esp,0Ch  
004019AA 68 D6 10 40 00       push        offset ___vbaExceptHandler (4010D6h)  
004019AF 64 A1 00 00 00 00    mov         eax,dword ptr fs:[00000000h]  
004019B5 50                   push        eax  
004019B6 64 89 25 00 00 00 00 mov         dword ptr fs:[0],esp  
004019BD 6A 18                push        18h  
004019BF 58                   pop         eax  
004019C0 E8 0B F7 FF FF       call        VB@TEXT (4010D0h)  
004019C5 53                   push        ebx  
004019C6 56                   push        esi  
004019C7 57                   push        edi  
004019C8 89 65 F4             mov         dword ptr [ebp-0Ch],esp  
004019CB C7 45 F8 C0 10 40 00 mov         dword ptr [ebp-8],offset __imp___CIexp+34h (4010C0h)  
004019D2 8B 45 08             mov         eax,dword ptr [Me]  
004019D5 83 E0 01             and         eax,1  
004019D8 89 45 FC             mov         dword ptr [ebp-4],eax  
004019DB 8B 45 08             mov         eax,dword ptr [Me]  
004019DE 24 FE                and         al,0FEh  
004019E0 89 45 08             mov         dword ptr [Me],eax  
004019E3 8B 45 08             mov         eax,dword ptr [Me]  
004019E6 8B 00                mov         eax,dword ptr [eax]  
004019E8 FF 75 08             push        dword ptr [Me]  
004019EB FF 50 04             call        dword ptr [eax+4]  
    Dim MyArray() As MyUDT
    
    ReDim MyArray(0 To 10) As MyUDT
004019EE 6A 00                push        0  
004019F0 6A 0A                push        0Ah  
004019F2 6A 01                push        1  
004019F4 68 34 16 40 00       push        offset ___vba@080D2FB0 (401634h)  
004019F9 8D 45 E8             lea         eax,[MyArray]  
004019FC 50                   push        eax  
004019FD 6A 08                push        8  
004019FF 6A 00                push        0  
00401A01 E8 84 F7 FF FF       call        @__vbaRedim (40118Ah)  
00401A06 83 C4 1C             add         esp,1Ch  
    GoSub FIND_TEMP_ZATR
00401A09 8D 45 DC             lea         eax,[unnamed_var1]  
00401A0C 50                   push        eax  
00401A0D E8 72 F7 FF FF       call        ___vbaGosub (401184h)  
00401A12 85 C0                test        eax,eax  
00401A14 75 02                jne         Form1::Form_Click+74h (401A18h)  
00401A16 EB 02                jmp         Form1::Form_Click+76h (401A1Ah)  
    
HELL:
    'ReDim MyArray(0 To 20) As MyUDT       '<---- errors here w/ "This array is fixed or temporarily locked"
    'Debug.Print UBound(MyArray)
    Exit Sub
00401A18 EB 1B                jmp         Form1::Form_Click+91h (401A35h)  
    
FIND_TEMP_ZATR:
    With MyArray(5)
00401A1A FF 75 E8             push        dword ptr [MyArray]  
00401A1D 8D 45 E4             lea         eax,[unnamed_var1]  
00401A20 50                   push        eax  
00401A21 E8 52 F7 FF FF       call        ___vbaAryLock (401178h)  
00401A26 6A 05                push        5  
00401A28 FF 75 E4             push        dword ptr [unnamed_var1]  
00401A2B E8 4E F7 FF FF       call        @__vbaDerefAry1 (40117Eh)  
00401A30 89 45 E0             mov         dword ptr [unnamed_var1],eax  
        GoTo HELL
00401A33 EB E3                jmp         Form1::Form_Click+74h (401A18h)  
    End With
    Return
End Sub
00401A35 C7 45 FC 00 00 00 00 mov         dword ptr [ebp-4],0  
$L27:
00401A3C 68 62 1A 40 00       push        offset $L50 (401A62h)  
$L26:
00401A41 8D 45 E4             lea         eax,[unnamed_var1]  
00401A44 50                   push        eax  
00401A45 E8 28 F7 FF FF       call        @__vbaAryUnlock (401172h)  
00401A4A 8D 45 E8             lea         eax,[MyArray]  
00401A4D 50                   push        eax  
00401A4E 68 34 16 40 00       push        offset ___vba@080D2FB0 (401634h)  
00401A53 E8 0E F7 FF FF       call        @__vbaAryDestruct (401166h)  
00401A58 8D 45 DC             lea         eax,[unnamed_var1]  
00401A5B 50                   push        eax  
00401A5C E8 FF F6 FF FF       call        ___vbaGosubFree (401160h)  
$L48:
00401A61 C3                   ret

The codegen cleanup uses a hidden local variable to keep track of MyArray locks and on cleanup unlocks it based on the state of this var just before automatically destroying the dynamic array (which is very similar to manual Erase MyArray).

If the __vbaAryUnlock call is skipped the cleanup on __vbaAryDestruct raises run-time error "This array is fixed or temporarily locked" indicating the deallocation failed, the same error ReDim/Erase would raise in manual VB6 code.

The codegen cleanup uses a hidden local variable to keep track of GoSubs executed too (probably a linked list or some kind of stack so that matching Returns know where to jump to) which is cleaned up with a ___vbaGosubFree call apparently.

So it seems native code codegen is very much battle hardened to prevent leaks on unexpected interactions. Could be OP code is still bugging it but without dissassembling it locally it is hard to say anything.

I'm compiling this with No optimizations + Gen symbolic PDBs so fiddling with other native code compilation options might introduce codegen problems related to array locking as well.

cheers,
</wqw>

[Nouyana]

If you need further help it would be nice if you could provide a small "working" sample project to see the issue (to study the first or the second issue).
I remember about the locked array issue but can't remember right now the details without seeing code.

Everything turned out to be a little simpler.

This code works fine in P-Code,
but it will hang your app in Native Code:

Private Type T1
   n As Integer
End Type

Private Sub Form_Click()
   Dim a() As T1
   Dim i   As Integer
   
   ReDim a(1 To 3)
   
   For i = 1 To 3
      Do While True
         With a(2)
            .n = 20
            Exit Do
         End With
      Loop
   Next
End Sub

[Eduardo-]

Yep, there seems to be a bug with the With statement and this special case.
The solution is not to use With.
There are some bugs in VB6, not many but from time to time we discover a new one.

[Nouyana]

Yep, there seems to be a bug with the With statement and this special case.
The solution is not to use With.
There are some bugs in VB6, not many but from time to time we discover a new one.

Or not to use Native Code

Today I've tested my app in P-Code and in Native Code. Speed is equal for both cases.

Thanks to everyone who participated in this discussion.

[DataMiser]

Sometimes I can just copy/paste a piece of code between VB6 and VBA. As you know VBA uses P-CODE.

That is the oddest reason I have ever heard to use p-code.

You do know that there is absolutely no difference in the code. The selection for p-code or native code are simply compile time options. The resulting exe will be different but the source code is the same.

[Nouyana]

That is the oddest reason I have ever heard to use p-code.

You do know that there is absolutely no difference in the code. The selection for p-code or native code are simply compile time options. The resulting exe will be different but the source code is the same.

We talked about using / not using the GoSub instead of normal Sub. GoSub works faster in VBA (because of P-Code), so you should use it for speed optimization.

[DataMiser]

I definitely do not and will not use gosub. Last time I used that was GWBasic. Sub routines and native code are the way to go.

[Niya]

Is there any justifiable reason to use GoSub/Return today?

[dz32]

the with statement normally causes the compiler to emit matching calls to __vbaAryLock / __vbaAryUnlock
when entering and leaving the with block

when the exit do is encountered no corresponding __vbaAryUnlock is generated by the compiler.

On function exit vbaAryDestruct -> __vbaErase -> ErrErase

ErrErase checks for locks and returns error code 10
__vbaErase calls EbRaiseExceptionCode which is caught by the exception handler vb automatically puts at the top of the user function

endless error loop ensues

this happens with optimizations off as well.