cdickerson
asked on
Memory Errors in Large Application
I'm working on a poorly-designed app with 97 forms, 38 bas modules, and 61 classes, all contained in one executable (over 7 megs). In addition, there are calls to 10 external dlls, including some Win APIs. The clients have 64 or 80 megs of memory, and plenty of available disk space.
The problem is that we're experiencing random, intermittent VB application errors - memory couldn't be written/read - that typically aren't reproduceable. 7 machines can be running the exact same source code, but don't experience the same problems at the same time.
Can anyone point out some areas that should be investigated as the source of these problems? Surely executable size is one of them. How large can VB reasonably handle one exe? What other culprits might be involved?
The problem is that we're experiencing random, intermittent VB application errors - memory couldn't be written/read - that typically aren't reproduceable. 7 machines can be running the exact same source code, but don't experience the same problems at the same time.
Can anyone point out some areas that should be investigated as the source of these problems? Surely executable size is one of them. How large can VB reasonably handle one exe? What other culprits might be involved?
I think You're running near the limit of objects VB can handle, that is, VB doesn't give You warnings whenever compiling the app but at run time it hits its limits and crashes miserably, I suggest You to take a look at VB documents about project limitations (objects, forms and so on) and to check out if it's the case, it the problem is this then You'll need to sit back and think about redesigning Your app splitting it in different pieces (EXEs) and linking them together by wrapping them inside some ActiveX "macro" classes
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Does this code have any error handling? Do you know exactly what is happening when the sporatic crashes occur?
FYI NuMega makes a product called FailSafe (I have downloaded a trial version, but haven't had the time to unzip and play with) which presumably would aid in identifying the failure points, i.e., call stack, memory state, blah, blah .... However this wouldn't necessarily tell U squat about the root of the problem. NuMega business is predominately (to my knowledge) debugging and they have branched into the VB. They have other tools which are diagnostic in nature, but my experience with their C/C++ tools (possibly not relevant to the VB tools) is that the tools gag on large complex applications. I suspect that the utility of these IDE add-ons is when it is used during development to avoid problems as the are developing, not just looking at the resultant beast and expecting a magic bullet, like fix this one memory leak and life will be good.
Ok, I'm off my soapbox.
BTW, I would be interested to here from anyone who is using the NuMega VB Suite and has comments.
HTH
FYI NuMega makes a product called FailSafe (I have downloaded a trial version, but haven't had the time to unzip and play with) which presumably would aid in identifying the failure points, i.e., call stack, memory state, blah, blah .... However this wouldn't necessarily tell U squat about the root of the problem. NuMega business is predominately (to my knowledge) debugging and they have branched into the VB. They have other tools which are diagnostic in nature, but my experience with their C/C++ tools (possibly not relevant to the VB tools) is that the tools gag on large complex applications. I suspect that the utility of these IDE add-ons is when it is used during development to avoid problems as the are developing, not just looking at the resultant beast and expecting a magic bullet, like fix this one memory leak and life will be good.
Ok, I'm off my soapbox.
BTW, I would be interested to here from anyone who is using the NuMega VB Suite and has comments.
HTH
The most common memory related errors are caused by:
Running out of GDI resources because of having too many windows open - and/or hiding windows instead of unloading them. Be sure that when the application closes a window it unloads it, then sets [form name] = nothing.
Too many controls on a form - usually not an intermittant problem - limit of 255 controls per form.
Dynamically allocating too much string space. I think there is a 64K limit to the amount of space you can dynamically allocate (try redimming an array to hold 10,000 text lines and you'll probably hit this error). Be careful of recursive routines that declare a lot of local variables, as this will cause the same problems.
Coding forms or modules with more than 64K of code (codespace is limited to 64K per module)
You can also get the error you mentioned when calling external DLL functions if you are not careful about passing the parameters correctly. Remember, VB passes everything by reference (by default) except Strings which it always passes by value - however when passing strings you should always explicity put the word ByValue in front of the string parm in the declare statement as this tells VB to append a null termination character to the string (which most C programs expect).
Also, be aware that some of the Declare statements in the WinAPI help file are incorrect, they might miss the ByValue in front of some strings, or they might declare something as Long (or whatever) when it might be an optional parameter and should be declared "as Any".
Very rarely, will you have problems with referencing deallocated variables, but if you are doing any multi-threading, this is a constant cause of this error.
Hope this gives you something to go on.
MD
Looks like dm_14 and I were typing at the same time, sorry for the duplication. Also, as for the size of the EXE. Yes, it is excessive, but I have seen VB apps that size that were successful. Windows swaps code in and out of memory if necessary, but with the amount your users have, it shouldn't be a problem (maybe it will be slower). Perhaps, as someone suggested, you could split this out into two or three related applications?
Running out of GDI resources because of having too many windows open - and/or hiding windows instead of unloading them. Be sure that when the application closes a window it unloads it, then sets [form name] = nothing.
Too many controls on a form - usually not an intermittant problem - limit of 255 controls per form.
Dynamically allocating too much string space. I think there is a 64K limit to the amount of space you can dynamically allocate (try redimming an array to hold 10,000 text lines and you'll probably hit this error). Be careful of recursive routines that declare a lot of local variables, as this will cause the same problems.
Coding forms or modules with more than 64K of code (codespace is limited to 64K per module)
You can also get the error you mentioned when calling external DLL functions if you are not careful about passing the parameters correctly. Remember, VB passes everything by reference (by default) except Strings which it always passes by value - however when passing strings you should always explicity put the word ByValue in front of the string parm in the declare statement as this tells VB to append a null termination character to the string (which most C programs expect).
Also, be aware that some of the Declare statements in the WinAPI help file are incorrect, they might miss the ByValue in front of some strings, or they might declare something as Long (or whatever) when it might be an optional parameter and should be declared "as Any".
Very rarely, will you have problems with referencing deallocated variables, but if you are doing any multi-threading, this is a constant cause of this error.
Hope this gives you something to go on.
MD
Looks like dm_14 and I were typing at the same time, sorry for the duplication. Also, as for the size of the EXE. Yes, it is excessive, but I have seen VB apps that size that were successful. Windows swaps code in and out of memory if necessary, but with the amount your users have, it shouldn't be a problem (maybe it will be slower). Perhaps, as someone suggested, you could split this out into two or three related applications?
ASKER
Thanks!
It seems that this is not a good written application