HP3000-L Archives

July 2001, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Steve Dirickson <[log in to unmask]>
Reply To:
Steve Dirickson <[log in to unmask]>
Date:
Mon, 9 Jul 2001 23:41:32 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (23 lines)
> That's odd.  So I start the usual debugging stuff.  CSREG1 is
> invoked from
> CSREG0, but all tracing stops at that point, so I figure I'll add the
> "strategicly-placed PRINT statements" and find out how far
> through CSREG1 its
> getting and that will point me to the problem.  No luck.  If
> I add a print
> statement--even one which doesn't get called, the problem
> goes away.  If I take
> it out again, it comes back.  Any clues as to what in the
> world is going on?

I see you found the problem, but I'll add this FWIW: the paragraph above is
a classic symptom of a wild-pointer problem--an improperly initialized or
erroneously-overwritten address value gets passed to something that tries to
dereference it, and the computer becomes very unhappy. Programmers in BASIC
or Pascal don't get to directly abuse pointers the way we C types do, but it
can still be done, especially when you're interacting with intrinsics that
take addresses of things in your program as parameters.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2