Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Prevasive and VB 432 bit code

Status
Not open for further replies.

albar

Programmer
Feb 15, 2002
19
0
0
US
Hi all! I have VB 4 32 bit code (I know, but we are small company!) that is only slightly modifed from exactly similar code (that works flawlessly) in another application-I added some file constants and definitions that this new app needs. Code mostly follows the examples provided by Pervasive API for using Visual Basic. I use an array of type string for the position blocks- the 22 entries of 128 bytes each is the biggest offender for space usage. Each file has it's own buffer defined, etc.

The application does data verification(not empty, valid for the tables/fields, etc) BEFORE doing any record commits. Record commits consist of updates in existing records and insertion of new records.

Issue: Performing the operations too many times w/o restarting the program caused error 28 out of stack space errors. Each operation consists usually of file updates at most on 4 records, at most I have seen up to 12 records.

Issue: Subsequent error code modifications to catch error 28 errors yield a program that simply DISAPPEARS at random, e.g. when closing a form after doing some file manipulations, updates or insertions; it is not visible in Task manager or via any other excellent process viewers(SysInternals) and can be restarted (with similar results :( )

The code compiles to less than 512K.

There is only one exit point for the entire program and it is only called from a main form when a specific button is clicked.

Begin, End Transaction are used to keep the files in sync, and Abort Transaction if any errors arise to roll back errors.

There is no explicit recursion. Have checked controls' Click() code and moved/removed code in an attempt to find/avoid the dreaded 'black hole recursion' that occurs when events are called that call events that call events that .... - I might still have some, but I put in a logging function (in EVERY routine!) and did not get anything that looked out of the place; everything opened/occurred/closed in normal sequence.

I DO use constants, but again the code is nearly identical to code in (an)other app(s) that never fails. I did attempt to remove these constants and use literals instead - same result.

Running compiled code or executing via the IDE gives the same results.

I have not yet attempted to step through the code line by line, and will do so ASAP, but am loath to do so as it would take probably as many hours to generate the error as I have already spent tracking down the problem!

Any ideas? This has already taken way too much of my time for what should be a relatively simple application.
 
Forgot to add:
Pervasive Version 8.60.192.030
Server = Win2K (NT on develpment side)
Client = XP
 
Usually when a program disapears, it's crashed.
In terms of Pervasive, I've seen position blocks that haven't been properly initialized cause crashes. Personally, I use an array of bytes rather than a 128 byte string for the Position block.
If you can't narrow down which call causes the crash, then you'll need to step through the code.


Mirtheil
Certified Pervasive Developer
Certified Pervasive Technician
 
Thanks for the quick reply!

Yes, I assume it's crashed ;) Just never saw it totally disappear!

And I did have pos blocks defined as an array of bytes, didn't seem to make a difference...I'll go back to them because the Pervasive examples use them.

What I have is a generic routine CallBtrieveOperation (gets passed the btrieve opcode, posblk array index and key number). First thing the routine does is open the file with another routine (that is also passed the posblk index). I use an array to indicate if the file is already opened so I don't re-open the file multiple times. So all access to the posblk array is controlled via indexing. The only exception are the Transaction Control Calls, whcih uses it's own position block.

Another side effect at times is that I'll get a crash then a (n) ntdll.dll error.

Well, I guess it's step through the code time! Thanks again, mirtheil
 
Update: Found one (1) major flaw:
Dim s1 as string * 128
.
.
.
s1 = Space(512)
...
This var was only used once at start-up then nevr referenced again.
Fixed it, but still get random crashes.

Stepped through the code line by line; will not crash when stepping through.

The only exception when steppinng through the code is that occasionally when the button on the main form is clicked (calls UnLoadAllForms then Unload Me is the very last statement encountered) I lose the entire IDE, e.g. it "disappears" as is currently happening with the compiled program;not visible in any task list in any way/shape/form.

Small monetary reward offered to whomever can fix this! (mirhteil, are you up to it ? If so, I can go to your website and send you the code :) )
 
Unfortunately, I don't have VB4 anymore so I would only be able to look at it in the context of VB6. You might consider just posting up the code for the UnLoadAllForms and also the Form Unload code.


Mirtheil
Certified Pervasive Developer
Certified Pervasive Technician
 
Okay:
Note -> LogErr(stringvalue) opens a local file for append and immediately closes it
Public Sub UnloadAllForms(FormToIgnore As String)
LogErr "At: UnloadAllForms"
On Error GoTo Sub_Err
Dim F As Form
For Each F In Forms
If F.Name <> FormToIgnore Then
Unload F
Set F = Nothing
End If
Next F
Sub_Exit: On Error Resume Next
On Error GoTo 0
Exit Sub
Sub_Err:
Message "UnlAF: " & Error$
Resume Sub_Exit
End Sub
All forms except frmENVOCOptions have this:
Private Sub btnExit_Click()
LogErr "At: xyz"
On Error Resume Next
frmENVOCOptions.Show
Unload Me
On Error GoTo 0
End Sub
and frmENVOCOptions has:
Private Sub btnExitOtherOpts_Click()
LogErr "At: btnExitOtherOpts_Click"
CloseAllBtrieveFiles
CloseBtrieve ' Stop btrieve
CleanUP
UnloadAllForms Me.Name
Unload Me
End
End Sub
where:
CloseAllBtrieveFiles contains a for next loop that calls btrcall(BCLOSE...) for any file marked open
CloseBtrieve calls BTRCALL(BRESET then BTRCALL(BSTOP
CleanUP closes an open file (a global local workstation file is used to swap out the data buffers to fix the alignment problems in VB32) and sets a boolean array (to indicate a btrieve file is already open) to Empty

This is a most irritating problem! Ready to give up my position and go flip burgers for a living...

 
Well, stepped through the code about a million times - no good. I can step through it and never get a failure. But if I compile it and run or just let it run inside the IDE, it will fail at various times. The newset oddity is one or two operations will work fine, but when I close the app, I get a 'the memory referenced cannot be read' error (not an error report type message or GPF, more like a MegBox). Looks like a memory leak, but I'll be darned if I can find it.
I have logged output and not seen any run away recursion.
I have verified data structures are of adequate length (btrieve complains about that anyway!) and routines that hit these structues have been checked to see that I'm not writing beyond the variables' length.
I have verified parameter types match what is expected, and tried CLng and CInt to force types when using variables in calls.

Any other suggestions would be greatly appreciated. I'd be willing to send the entire Project along to some masochistic person who'd like to torture themselves by looking at it!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top