DOS ain't dead

Not widely known problem in programming? (Developers)

posted by Laaca , Czech republic, 27.03.2021, 20:06

I would like to share my experience with source of several my very mysterious programming bugs. In several cases I for many hours tried to debug some part of my program and was not able to find the bug. Sometimes I've given to up and sometimes I've avoided the problem with some ugly hack but never really found what was wrong.
The typical symptom is that everything works just fine but it stops working after some change in program - usually in very different part of program. The term "stops working" means that the program crashes. Sometimes crashes only the program but sometimes whole DOS.
The debugger usually reports the error into some graphic procedure but it is apparently misleading.

Recently I investigated such behaviour in my editor Blocek and found the reason. I suspected some uninitialised pointer bug (known and frequent problem) but found something what was new for me.

In several pieces of my code I found that I am referencing global pointer to local stack.
The problem is that everything works OK for very long time but "sometimes" - usually in assembler graphic functions which work with such pointer the crash occurs.
Such function touches the memory where before was our data by own purposes and because of that the referenced value is overwritten and the behaviour is after that undefined.
I tried to strip the problem to be the example as simple as possible. Look at the code bellow. The bug is in the procedure "Test_Obj.Init" where I am assigning the "message" pointer into local stack.
Than the Test_Obj.Display works but there is still the permanent danger that in case of extending the program the incrimined part of memory will be overwritten and the program will crash or will not work in the right way.
Maybe you thing that I am stupid because such obvious bug can make only a idiot but trust me - if is it a real-life code (not this trivial sample) it can be very difficult to find it.

Have you ever faced to this type of bug?
Does the compilers (I am interrested mainly inf Freepascal) have some mechanism which does -something- with the local stack to demask such latent programming bug?

And the promised code example:

Program ObjTest;
type
test_obj=object
message:pchar;
procedure Init;
procedure Display;
end;

Procedure test_obj.Init;
var s:string;        {variable on local stack}
begin
s:='Hello'#0;
message:=@s[1];      {public reference to local stack}
end;

Procedure test_obj.Display;
begin
writeln(message);
end;

var to:test_object;
begin
to.Init;
to.Display;
end.

---
DOS-u-akbar!

Complete thread:

• Not widely known problem in programming? - Laaca, 27.03.2021, 20:06 (Developers)
  • Not widely known problem in programming? - ecm, 27.03.2021, 20:30
    • Not widely known problem in programming? - tkchia, 28.03.2021, 08:02
      • Not widely known problem in programming? - marcov, 28.03.2021, 17:44
      • Not widely known problem in programming? - bretjohn, 29.03.2021, 20:03
        • Not widely known problem in programming? - Laaca, 29.03.2021, 22:24
          • Not widely known problem in programming? - bretjohn, 29.03.2021, 23:02
            • Not widely known problem in programming? - marcov, 30.03.2021, 12:05
        • Not widely known problem in programming? - ecm, 29.03.2021, 22:26
  • Not widely known problem in programming? - ecm, 28.03.2021, 21:52
    • Not widely known problem in programming? - Laaca, 29.03.2021, 05:04