Corrupted String Space Problem 
Author Message
 Corrupted String Space Problem


Quote:
HART) writes:
>(Using QB4.5)
>It runs fine.  After editing/running a few times I get the (QB, DOS or
>QEMM?) error message: (rather rudely pasted across the editor screen)

> 'string space corrupt'

> 'hit any key to return to system'

This is definitely the compiler's message. The problem is most likely with
your program's writing data to weird parts of the memory. Check all your
POKE and CALL ABSOLUTE (if any) routines to make sure it doesn't write to
some odd places.

-Mark



Sat, 18 Jul 1998 03:00:00 GMT  
 Corrupted String Space Problem
I am not sure about 4.5, but am sure it functions similar to later
versions in the manner I will speak.

1) Go through and verify the number of arguments passed in all sub and
function usage. An arguement mismatch may not even show up in the
module which has the mismatch. Use a DECLARE statement when there are
many arguements, to avoid having to count them. The DECLARE should be
placed at the beginning of each module making the call, and can be
removed after debugging.

2)Compile each module with the /D switch. This will verify array
subscripts and generate an error if not valid. Using an out of bounds
subscript may not show up in the same module.

3)Use the STACK statement. The default is 3k. Making it larger reduces
the size of DGROUP memory and space for near strings, so this is a
tradeoff.

4)If memory problems cannot be resolved, use an external assembler
module containing all quoted strings, and call this module with an
arguement to represent each string.



Sat, 18 Jul 1998 03:00:00 GMT  
 Corrupted String Space Problem

So I've been continuing with a rather large project and have come into
this (I assume) memory problem.  The program consists of several modules
(needed 'cause of past memeory probs) with some needed COMMON SHARED
varibles spread around. And in SCREEN 9.  

Here's the problem:

(Using QB4.5)
It runs fine.  After editing/running a few times I get the (QB, DOS or
QEMM?) error message: (rather rudely pasted across the editor screen)

 'string space corrupt'

 'hit any key to return to system'

I hit a key (and harder each time!) and QB quits and I'm back to the DOS
prompt.

OR ocationally QEMM will break in and state that a memory conflict has
arose and I must reboot.

This is really causing the whole programing experience to be rather
frustrating.

I've assumed that the problem lies in the stack space and have tried
using CLEAR,, stack  , _BUT_ I cannot since It clears out the COMMON
SHARED information and CLEAR must go after the COMMON's.

Also I've minimized as much of the string varibles that I could, using
DIM AS, etc..

Any suggestions?  Am I on the right track?  Oh please help, this is
really starting to suck!  yikes!

Matt



Sat, 18 Jul 1998 03:00:00 GMT  
 Corrupted String Space Problem

Quote:

>So I've been continuing with a rather large project and have come into
>this (I assume) memory problem.  The program consists of several modules
>(needed 'cause of past memeory probs) with some needed COMMON SHARED
>varibles spread around. And in SCREEN 9.  

>Here's the problem:

>(Using QB4.5)
>It runs fine.  After editing/running a few times I get the (QB, DOS or
>QEMM?) error message: (rather rudely pasted across the editor screen)

> 'string space corrupt'

> 'hit any key to return to system'

>I hit a key (and harder each time!) and QB quits and I'm back to the DOS
>prompt.

>OR ocationally QEMM will break in and state that a memory conflict has
>arose and I must reboot.

>This is really causing the whole programing experience to be rather
>frustrating.

>I've assumed that the problem lies in the stack space and have tried
>using CLEAR,, stack  , _BUT_ I cannot since It clears out the COMMON
>SHARED information and CLEAR must go after the COMMON's.

>Also I've minimized as much of the string varibles that I could, using
>DIM AS, etc..

>Any suggestions?  Am I on the right track?  Oh please help, this is
>really starting to suck!  yikes!

>Matt

This may or may not help, but another way to use COMMON SHARED...

msg$="this is a test"
RunThisTestSub
END

SUB RunThisTestSub
    shared msg$
    ? msg$
END SUB

...You can eliminate the COMMON SHARED at the top of your program if you simply
use SHARED inside of each SUB.  Include ONLY the variables that you intend on
using within the SUB itself. (WORKS on FUNCTION also)...

a=3
b=4
? CalculatedData
END

FUNCTION CalculatedData
         SHARED a,b
         CalculatedData=sqr(a^2+b^2)
END FUNCTION

hope this helps...

Beau Schwabe



Mon, 20 Jul 1998 03:00:00 GMT  
 Corrupted String Space Problem

: ...You can eliminate the COMMON SHARED at the top of your program if you
: simply use SHARED inside of each SUB.  Include ONLY the variables that you
: intend on using within the SUB itself. (WORKS on FUNCTION also)...

Unfortunately, :(, the SHARED by itself will not allow me to share values
with other modules, of which I have about four that need sharing.

Matt



Tue, 21 Jul 1998 03:00:00 GMT  
 Corrupted String Space Problem

: I am not sure about 4.5, but am sure it functions similar to later
: versions in the manner I will speak.

: 1) Go through and verify the number of arguments passed in all sub and
: function usage. An arguement mismatch may not even show up in the
: module which has the mismatch. Use a DECLARE statement when there are
: many arguements, to avoid having to count them. The DECLARE should be
: placed at the beginning of each module making the call, and can be
: removed after debugging.

-Done

: 2)Compile each module with the /D switch. This will verify array
: subscripts and generate an error if not valid. Using an out of bounds
: subscript may not show up in the same module.

-Done

: 3)Use the STACK statement. The default is 3k. Making it larger reduces
: the size of DGROUP memory and space for near strings, so this is a
: tradeoff.

-Not a command in QB4.5 (only  CLEAR,,stack  which screws other stuff up.)

: 4)If memory problems cannot be resolved, use an external assembler
: module containing all quoted strings, and call this module with an
: arguement to represent each string.

-This I will now try in  one form or another.
Thanks!

Matt



Tue, 21 Jul 1998 03:00:00 GMT  
 Corrupted String Space Problem
I have been thru that land also.  Many of my problems did solve by having
reduced the number of global variables or the size of global variables and
using procedures with parameters.  I've heard that the common area
can't exceed 64k, so please check.

Also, remember Basic can receive data thru parameters *AND* return data
thru parameters.  This way you can return arrays, record types, etc.
without going thru the problem of having string space problems.

The problem can rise because (in the case you're using third
party quick libraries), some unruly pointer is not behaving.  Check this
also.  Many libraries have problems communicating with memory managers, so
maybe there is a problem with QEMM, or EMM386.

                                  -- Ivn --



Wed, 22 Jul 1998 03:00:00 GMT  
 Corrupted String Space Problem
When I want to use the assembler module option, I give each BASIC file
the extension .LIT. This is because they contain string literals. I
wrote a program which reads each .LIT file, looks up each literal
string in a database, and returns an index number. If the string
already exists in the database, it returns the existant number, and if
not, the string is added. In the BASIC source is put a replacement for
the original string, such as LIT$(0137). When all source code has been
processed, the database is dumped to a sequential ascii file, in the
order entries were added. Once you have this sequential ascii file,
and you have modified source code, you have two options. One option is
to distribute this sequential file with the program. Dimension a
LIT$() array in the FAR HEAP and read the file into it. This was my
original method, but keeping up with the literals file is a pain in
the ass. It is a good option, however, and may work for you. It is the
easist to implement. The second option is to have an assembler module
shell. Both the shell and the literals file is read by a program,
which creates an assembler module. This module is assembled, and the
OBJ linked with the other modules. One complete .EXE is produced.
When I do not want my text changed, I use a little encryption in the
assembler module. Not much can be used however, since this string data
is used in real time and there is a moderate delay. When no encryption
is used, there is virtually no delay. String space is deallocated for
the previous call, then allocated again, so this represents the only
delay.


Fri, 24 Jul 1998 03:00:00 GMT  
 Corrupted String Space Problem

: When I want to use the assembler module option, I give each BASIC file
: the extension .LIT. This is because they contain string literals. I
: wrote a program which reads each .LIT file, looks up each literal
: string in a database, and returns an index number. If the string
: already exists in the database, it returns the existant number, and if
: not, the string is added. In the BASIC source is put a replacement for
: the original string, such as LIT$(0137). When all source code has been
: processed, the database is dumped to a sequential ascii file, in the
: order entries were added. Once you have this sequential ascii file,
: and you have modified source code, you have two options. One option is
: to distribute this sequential file with the program. Dimension a
: LIT$() array in the FAR HEAP and read the file into it. This was my
: original method, but keeping up with the literals file is a pain in
: the ass.

ok, but....

Far Heap? Are you refering to the AH compiling option?
Matt



Sun, 26 Jul 1998 03:00:00 GMT  
 Corrupted String Space Problem

ok, but....

Far Heap? Are you refering to the AH compiling option?
Matt

I mean, to use far strings. Near strings go in DGROUP, or static
memory, and far strings go in FAR HEAP, or dynamic memory. These are
defined segments. Using DIM with a constant for the number of
elements, places the array in static memory. Using a function or
variable for the number of elements, places the array in dynamic
memory. REDIM instead of DIM, always uses dynamic memory. String
arrays always go in static memory, regardless how they are
dimensioned, unless the /Fs switch is used on the BC command line,
then they are optionally placed in dynamic memory, depending on how
they are dimensioned. The interpretor uses far strings

Obviously, use of dynamic memory allows much larger arrays. The point
is to increase space available in static memory.

I would also add, if a large text file is read into a string array,
the original source file, containing string literals, can be compiled
and linked at any time. It is sometimes necessary to debug and work
with one module. It would be ridiculous to recompile all modules, over
and over again, after one little change is made. Once the problem has
been resolved, then all can be done together once more.

I have never found a need to use the /AH option.



Thu, 30 Jul 1998 03:00:00 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. QB45-String Space Corrupt

2. String Space Corrupt error: Solved!

3. QB45 with Assembler: String Space Corrupt!

4. "String Space Corrupt" in QB 4.5

5. string space corrupt error

6. Space Space Space Space Space Space Space

7. Space Space Space Space Space Space Space

8. Space Space Space Space Space Space Space

9. disabling the space key or removing a space from a string

10. Function to Squeeze multiple spaces in a string to one space

11. Quickbasic String Space Problems

12. problems with string: quotes and spaces

 

 
Powered by phpBB® Forum Software