kam@itivax.iti.org (Keith A. McNabb) (03/08/90)
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.orgLAUFMAN-H@osu-20.ircc.ohio-state.edu (Harry Laufman) (03/13/90)
Regarding...> 8 Mar 90 15:13:28 GMT kam@itivax.iti.org (Keith A. McNabb) > Juicy TP5.5 Problem >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. Months ago I wrote a data analysis graphics package for our lab data and had a similar problem. The data didn't plot correctly. I was using two (w,x) out of four (w,x,y,z) parameters for a scatter plot, and the program cycled, plotting (w,x), then (x,y), then (y,z) and so on. In Debug (Turbo's) things were fine. If I added one line of code, either a debug outtextxy('Values are...') or a pointless x:=x+1-1; program runs ok. A call to Borland and I was told to be sure to initialize ALL variables. I did...problem solved. Don't know exactly why.