#Value of Enforcer
28 messages in this thread
I have a problem with debugging. At some point in my code, after it has
been running for some time, something goes wrong and weird things happen.
I have tried to trap all MOVE instructions to check for invalid memory
access, to no avail. I therefore suspect that the problem occurs in a
library call.
My question is, would a utility such as Enforcer be of any help? I
currently do not have an MMU, and would need a good reason to buy one. I
understand that Enforcer will catch writes to address 0. This does not
help me, as I know for sure that this does not happen with my software.
What else does Enforcer and related software offer?
Regards,
Shraddhan (via AP from Hertfordshire, England)
Others may comment on the value of Enforcer, but allow me to add another
suggestion: check for a stack overrun. If, as you say, the program works OK
"for some time", I would guess that most of your library call setups have been
used during the run. So: what are you taking that you don't put back? Stack?
Memory (esp. chip memory via Screens, Windows, etc.?)
Look at any memory allocations you use and make sure you don't overrun their
areas. This includes structures that the system may supply to you.
If your problem is indeed in this area, you may find that MungWall is a more
useful debugging utility.
–Jim
> check for a stack overrun
The problem isn't here – the program checks the stack at certain critical
points, and hasn't issued a warning. Also, a utility confirms that at
worst I still have 16K of stack unused.
> the program works OK "for some time"
I should have added that this time seems to be quite random 🙁
If I put a break point in the program, it fails before reaching it, or
doesn't fail after the break point. Usually there's no crash, just maybe
another program stops working, or my program pops up an illogical error
message, or the AmigaDOS COPY program gurus…
> what are you taking that you don't put back?
Nothing that I can think of – the computer doesn't run out of memory, and
while the program is running, no windows are opened are closed. Also,
before returning any memory, its contents are first overwritten to try to
force a crash if the memory is accessed in error by my program. And it's
not a hardware problem – all of my other software runs fine.
I've spent a lot of time developing tools to help track down this problem,
all to no avail. That's why I'm wondering if something like Mungwall
could help, in which case, I would have to go to the trouble of replacing
the processor with one which has an MMU.
Regards,
Shraddhan (via AP from Hertfordshire, England)
I hope that we may yet see other useful postings suggesting the next step in
tracking down your troubles. I'm just scattering shots in case any of my
suggestions ring a bell (is that a mixed metaphor or what?)
I believe that MungWall doesn't need an MMU. Its principal advantage is that
it carefully tests all allocated memory to see that it's put back properly and
is not overrun (it actually surrounds the allocated memory with tokens, and
checks that they have not been smashed when the memory is returned).
I wonder if it's worth checking what other processes are active in your
machine. If you're loaded down with utilities, hot keys, screen savers, and
whatnot, it *might* turn out that one of these are triggering a malfunction in
your program. Try taking 'em out to see if the problem goes away.
Certainly wouldn't hurt to put MungWall in there. As you commented, it's a
judgment call as to whether it's worth while adding an MMU in order to get
Enforcer in action. ANYONE?
–Jim
Many thanks for you suggestions. I've had another look at the code I
wrote to check that my MOVE instructions had valid addresses, and noticed
that unfortunately it only checked the destination addresses, and not very
carefully either.
I've spent the day re-writing this code and have come to realise that it
can be an enormous help to catch invalid _reads_ as well as writes. I
have since detected two bugs, one of which may well have been the cause of
my problems. (I haven't managed to fix it yet.)
As for an MMU, I still can't decide whether or not to invest in one. My
error checking code, when it is activated, slows down processing by a
factor of 50, and a hardware solution (if a really good one exists) would
therefore be much more practical.
I've found a copy of Mungwall, version 37.51 and the docs make no mention
of an MMU, so I guess I'd better try it out.
Regards,
Shraddhan (via AP from Hertfordshire, England)
Enforcer would catch alot(!) of invalid reads and would not slow your code
down %50. Think about getting an MMU. I got a real 68030 to attempt to
catch a bug in a program I am writing, but, alas, that isn't the problem.
However, I like to run Enforcer just to catch other programs. You might
not beleive how many programs I've quit using because of oddball reads to
memory locations they have no reason to access.
Robb
> Think about getting an MMU
Yes, it certainly seems that I ought to get one. I'll order one
tomorrow.
(BTW, I have at last found the bug – at about the 25 millionth READ)
Regards,
Shraddhan (via AP from Hertfordshire, England)
25 million reads! Ouch!
Congrats on finding it.
Robb
Robert,
What programs have you quit using because of oddball reads?
TIA!
Sincerely,
(Mr.) Gayle Lee Fairless
'Perfessor Fearless' from the Rocket City!
via AutoPilot 1.03a
Robert,
I'm so fond of enforcer and mungwall that I run them ALL the time on
the 3000. Amazing what programs you find that have bugs in them, not
simply your own.
Well, I do have many problems with mungwall. I like the program, but it
doesn't seem to be reliable. I just discussed the problems today with
other developers and they too seem to have similar problems with the
latest mungwall (V.71).
For instance: in some cases a CreateNewProc didn't worked as long as
mungwall is running (seems to depend on the WB/KS version).
When I run my program with mungwall and the TASK and NAMETAG option, lot's
of mungwall hits are reported. But none of them seems true and hits seem
to be caused by intuition. Also, no hit is reported when not using the
TASK option (huu?).
When I manualy trash memory after my alloced mem, mungwall does not report
a hit (huu? isn't that the main task?). Sometimes it works… sometimes
don't.
The docs are not clear about wether AllocVec() is handled or not. I
allways use AllocVec() and maybe this is the problem…
— Wolf Faust, Am Dorfgarten 10, 60435 Frankfurt, Germany —
Wolf,
Well, I'm using 37.71 of mungwall and I haven't noticed any such
problems. I'm also using Kickstart 40.62, Workbench 40.29, so that might
be why. I updated mungwall to 37.70, but I don't know what differences
were put in for .71 (darn, was hoping to keep my source up to date). I
run mungwall like this:
run >nil: <nil: mungwall presize 64 postsize 64 nametag showpc showhunk
timestamp
maybe the extra bytes at the beginning and end shadow the problem. On the
other hand, I don't use the TASK option.
Do get and use Mungwall. If I may add a bit to what Jim said, Mungwall
also helps catch bad reads by filling unused memory with a special pattern
x'DEADBEEF'.
Mungwalls main disadvantages are that it slows your system down a small
bit and you use up your memory a bit faster because of the walls around
each memory allocation. So you may want to use Mungwall only while
testing.
And to add to what Steve said, yes you also want to use Enforcer. It will
catch any read or write to unavailable memory. Enforcer does not slow
your system down and it should be run all the time. Enforcers only fault
is that not all Amigas have an MMU and that not all developers use
Enforcer.
I feel that any program that will be released to the public should be
tested on an Amiga running Enforcer and Mungwall. Its not done as long as
there are hits reported by either program.
//
\X/ Amiga or bust! Gary Bonnstetter, Bonnsoft
Enforcer is the single most important and powerful debugging tool there
is, bar none.
-sja
Jumping in the middle (and so probably missing something valuable)…
>it's a judgment call as to whether it's worth while adding an MMU in
>order to get Enforcer in action. ANYONE?
The world would be a much better place if anyone who ever released any
Amiga software tested it thoroughly with Enforcer, Mungwall and
Memoration. The MMU is worth paying for.
(Memoration, in case you don't know, is a neat tool for denying memory
allocations. With the right settings, it can probablistly test most of
your error handling code.)
— Dale L. Larson, Intangible Assets Manufacturing
— INTERNET:dale@iam.com
Shraddhan,
Debugging code on the Amiga withOUT Enforcer is a waste of time. Of
course, I think that "MetaScope: The Debugger" is particularly useful too
<grin>.
> I think that "MetaScope: The Debugger" is particularly useful too
What's this "MetaScope: The Debugger"?
BTW, I've now got an MMU and have been using Enforcer, but unfortunately
it and the Devpac debugger are incompatible, in that the debugger would
like to read from (for example) address 0 in order to show me what's
there, and Enforcer doesn't like this one bit. ;-(
Regards,
Shraddhan (via AP from Hertfordshire, England)
Shraddhan,
re: "in that the debugger would like to read from (for example)…
address 0 in order to show me what's there, and Enforcer doesn't like… this
one bit."
Well, maybe you shouldn't look at 0 <grin>. Or are you saying that the
devpac debugger does this all by itself?
If you're running Enforcer, you'll want to pick up Mungwall and…
Segtracker.
MetaScope is available from Innovatronics and it IS compatible… with
Enforcer (it even 'stops' your program right after the 'hit' so… yuu can look
around.
Vic,
The Devpac debugger tries to show the contents of regions of memory
regardless of whether they are 'owned' by the program being debugged.
Also, it will try to show you the data pointed by the registers A0 to A7,
so if one of these happens to be zero, the debugger will read 20 or so
bytes starting at address 0. And, you can set a window to show memory
contents, and link the starting address to a pointer (or an expression
based on a pointer). Then when the pointer goes invalid – dozens more
Enforcer hits.
To avoid the risk of corrupting my hard drive, all files are written to
SD0: (a recoverable ram disk), but it doesn't take long for Enforcer to
use up the 4Mbytes I've allocated to SD0: when the debugger is running.
Maybe I'll look at MetaScope…
> You'll want to pick up Mungwall and Segtracker
I've got Mungwall. Haven't used it yet. I believe I have Segtracker, but
I don't remember looking at it. I don't need any debugging aids at the
moment, as I've fixed my coding errors, and am now only (!) having
problems with the program's logic. If only I knew what my program was
supposed to do… 😉
Regards,
Shraddhan (via AP from Hertfordshire, England)
"I don't need any debugging aids at the moment, as I've fixed my coding
errors …"
Famous last words spoken 10 minutes before a wild pointer takes out an
unbacked up hard disk.
-sja
I made a number of doozy statements like that at my first programming job. In
one, I left a note on my boss's desk on Friday that said that a certain
subroutine package might be up and running by Monday; in reality, it took about
nine more months with a team of programmers. Another was "these days, my code
compiles without error the first time." 🙂
Reminds me of a team meeting in a project I was on once. The team leader
asked how much more work needed doing on that 3 day job he had assigned at
the last meeting, and the reply was "About a month".
Peter Wade
Autopiloting from London, England
Ask John Toebes about the original Blink linker written by the Software
Distillery. We got together on Friday of Memorial Day weekend (end of May,
for you non-US people) and John said we could finish it by the end of the
weekend… we shipped it Labor day weekend of the same year (beginning of
September).
All in all, a 3300% slippage.
–Doug
John,
I've written only a couple programs that compiled error free the first
time (AND ran!!). They were on the order of complexity of a "Hello World"
program tho. Nothing more substantial has.
Steve,
re: "Famous last words spoken 10 minutes before…."
Yup.