Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!yale!ox.com!itivax!kam
From: kam@itivax.iti.org (Keith A. McNabb)
Newsgroups: comp.lang.pascal
Subject: Juicy TP5.5 Problem
Keywords: Turbo, bug
Message-ID: <5106@itivax.iti.org>
Date: 8 Mar 90 15:13:28 GMT
Organization: Industrial Technology Institute, Ann Arbor, MI.
Lines: 41

Has anyone seen instances where Turbo Pascal 5.5 goes in the weeds
just after entry to an overlaid unit?  I have pinpointed the spot
of the crash, and the code is harmless and well tested.  Also,
the location of the crash seems to depend on physical address, so
that the crash occurs at different places when the code grows or
shrinks.  If I place a debug message call at the spot, then the
message produces strange results and the surrounding code works
fine again.  Also, there are no suspicious pointers, strings, or
arrays anywhere near the scene of the crime.  The problem seems to
occur whether or not range and stack checking are enabled, although
the changes in size do affect which unit is "hit".

I'm wondering if:

  - An interrupt may be changing the data segment and not restoring
    it.  As evidence, the code continues to execute, but the 
    screen graphics it is building go all over the map.  Yet, on
    later calls to the same graphics routines, everything is fine.
    We are not using any assembly language calls or interrupt
    handling in the application, but we are using the Microsoft
    mouse driver and the MetaGraphics MetaShel.  All Pascal calls
    are forced to FAR, and overlays are enabled in all units which
    are overlayable.

  - Some of the MetaGraphics functions (for MetaWindows) we are
    calling actually complete on interrupt after the call has 
    returned, and our 25 MHz machine is outrunning them.
    (I really doubt this.)

I don't currently have a logic analyzer or microprocessor emulator
available, so I'm stabbing in the dark at this point.  The Turbo
Debugger is no help, as the problem is never observed when the
debugger is loaded and running.  I HAVE tried doing a sumcheck of 
the afflicted routine, but the sumcheck always comes out the same.

If any of this rings a bell, or if you relish the chance to feel like
Sherlock Holmes, your ideas would be appreciated.

Dr. Keith McNabb
Industrial Technology Institute, Ann Arbor
kam@iti.org