[comp.sys.ibm.pc.misc] TP overlays are not safe!

terra@diku.dk (Morten Welinder) (09/10/90)

Turbo Pascal 5.5 has a problem with the O+ switch; it doesn't work.



Setup: The following code is placed in an overlaid unit (#1):

  writeln(   pos(           { pos has 2 (>1) arguments, 1st is a string }
                 '.',       { 1st argument is string CONSTANT }
                 myfunc));  { calls other modules (#2,...). }


Problem:
  The expression '.' generates a reference to the code segment; CS and some
  offset is pushed. Then myfunc is called and (a pointer to) the result is 
  pushed. Finally pos is called.

  Since the second expression may cause unit #1 to be disposed of by the 
  overlay manager, there is 
  simply no way to ensure that unit #1 is reloaded at the same address before 
  the pos-function is evaluated. If it is reloaded elsewhere, the first 
  argument is LOST.

  The problem may arise with as little as three units. I will post source
  code when I can get my fingers at it.

  The problem only shows if little memory is available for the overlay buffer.
  Debugging consumes a large amount of memory.

Solution:

1. Yell at Borland

2. Take special care when using string constant as non last argument in an
   overlaid unit. Rearange the expression:
      s:=myfunc;
      writeln(pos('.',s));

3a.Make the overlay buffer large enough to hold all active units. (Then
   #1 will not be disposed of.)

3b.Do not change the size of the buffer. (The #1 will be loaded at the same 
   address.)



Morten Welinder
terra@freja.diku.dk

clong@remus.rutgers.edu (Chris Long) (09/13/90)

I've encountered another bug in Turbo Pascal 5.5.  The program in
question was well withn TP's weenie memory requirements, and to be
sure I broke it up into three units (the main unit was under 10k!).
The problem:  when compiled, TP gives me a strange error (like "line
or and pos funct" file not found) and then proceeds to remove my
program from memory.  Apparently TP5.5 doesn't like the fact that
I'm doing 40 or so nested while-do loops; perhaps it has some type
of stack which keeps track of this nesting and which gets so large
that it offs a chunk of memory (which the main unit is in!).

Has anyone else had a similar problem?

-Chris