keithd@well.sf.ca.us (Keith Doyle) (03/03/90)
Hi,
I posted this note about a Manx 5.0 SDB problem I was experiencing, and
haven't yet seen any response. This could be because I posted it to
comp.sys.amiga, not comp.sys.amiga.tech, so I am reposting it here
in comp.sys.amiga.tech. Could someone who has a 1Meg Agnes quickly
check this out and help me determine if it is a real bug or something
about my Agnes that is screwy? Thanks.
Text of previous posting:
-----------------------------------------------------------
Just discovered an apparent Manx 5.0 SDB bug, and have been interested in
hearing if anyone can reproduce it. I called Manx, and reported it
to them, but they hadn't yet heard of such a problem. [still no word,
as of 2nd posting] They may call me back about it [someday], but since
it could be somehow unique to my hardware, an attempt to reproduce the
bug on someone's similar configuration, could tell me if it's time to
fix the hardware.
Configuration:
3MB Amiga 2000 with 1MB Agnes. FD or HD doesn't matter, 68020 doesn't
matter.
Symptom:
Example program seems to run ok, BUT,
When using SDB's single-step command "t" on this program, it works ok
until you get to the "strcpy". The next "t" command causes the display
to go black (and I mean black. Don't think there is even a vert/horiz
sync).
If you edit out either of the assignment statements, it will work ok, or
(more importantly) if you replace your fat agnes with the original skinny
agnes, the problem will go away as well. Seems to be related to the fat
agnes, or perhaps just *my* fat agnes (though it's been working for months
with everything else). I seem to have a D-step part. (there's a little
"D" stamped on it anyway).
Compile and link the included C program using the following commands:
cc -ps -bs bugs.c
ln -g bugs.o -lc16
Then do:
sdb bugs
And finally, use the "t" command 3 or 4 times and see if it crashes
after the strcpy, or if it exits normally.
If you are unable to reproduce this bug on a 2000 with a fat agnes,
please let me know, as I may be able to get another agnes to cure
the problem. Otherwise, SDB has a real bug here, and its a serious
one as far as I'm concerned, as it seems like it may crop up elsewhere
in unpredictable places, and running without the fat agnes or SDB is a
real pain anymore.
---bugs.c--- cut here -----------------------------------------
/*
sdb bugs
*/
#include <stdio.h>
#include <string.h>
char pstr[81];
main()
{
short i;
short j;
j = 200;
i = 480;
strcpy(pstr,"Hello World\n");
printf(pstr);
exit(0);
}
----------end of bugs.c--------------------------------------------
Keith Doyle
well!keithdmartin@suna8.cs.uiuc.edu (03/04/90)
Well, my letter bounced, so here goes...
I tried your program on my machine (2000HD, 1Meg, 1Meg-Fat Agnus),
and sdb performed just as you described. Quite strange!
Please post any information you get from MANX about this problem! I
was upset enough that the upgrade didn't include a window to dynamically
observe variables like I have at work on IBM's running Turbo-C or
Zortech-C++! Now it appears that sdb needs further debugging itself!
Yikes. There, I feel much better now.
- Rocco
P.S. I found what appears to be a bug in Rob Peck's book "Programmer's
Guide to the Amiga". On page 17, he has a sample program that opens
the console and writes 'hello world' using a FileHandle, and fprintf().
Naively, I tried it and got a requester. Intuitively, it shouldn't
work anyway, since fprintf() needs a (FILE *), and the pointer is a
(FileHandle *). Anyway, just thought you'd like to know...greg@noel.CTS.COM (J. Gregory Noel) (03/05/90)
Keith Doyle (keithd@well.sf.ca.us) writes: >Example program seems to run ok, BUT, >When using SDB's single-step command "t" on this program, it works ok >until you get to the "strcpy". The next "t" command causes the display >to go black (and I mean black. Don't think there is even a vert/horiz >sync). Sigh. I, too, would like to know more about this problem. The example posted by Keith works just fine on my machine (thin Angus), but I have seen the symptoms he described too many times and I'd like to know how to fix it. I have a program that will run under SDB just fine for several times, but if I load it under SDB one time too many, the screen goes completely black as described above. The only cure is a reboot. For what it's worth, it's my feeling that the problem is not with SDB per se, but that SDB does something that tickles the problem area. It's my guess that my program has an errant pointer somewhere that is smashing some DOS structure and that when SDB tries to set up its windows, something ends up wandering off into never-never land. Why it would only be SDB that tickles the problem (the program seems to run just fine as long as I never use SDB, which is kind of difficult if I'm doing any debugging) I don't know. I've also observed that there is an interaction between SDB and improper argument lists -- I had a case where I could use SDB to single-step through a particular line of code just fine, but every time I ran it at full speed, the program would crash. It took a long time to narrow it down to the line that failed, at which point the problem was obvious -- the sscanf call had too many format items for the number of arguments.(*) I suspect that running a program under SDB uses the stack beyond the end of the current frame; it would only be a program like mine with errant arguments that would cause the problem to occur. In any event, if anybody has any suggestions as to what or where might be getting smashed to cause these problems, I'd appreciate knowing. If needs be, I can put in something that checks for damage after every line, but only if I can figure what's going wrong.... Thanks! -- J. Gregory Noel, UNIX Guru greg@noel.cts.com or greg@noel.uucp ____________________ (*) Does anybody have a tool that will check formats against the argument list and vet that the values are OK? I realize that it cannot be done for the general case, but even something that handled the simple cases (fixed format string, no calculations in arguments) would be useful. In fact, I'd like to see this as something that the Manx compiler offered; it would already have the modes of the arguments and it wouldn't be too hard to scan the format to see if the items matched.... What'd you think, Mike?
Sullivan@cup.portal.com (sullivan - segall) (03/06/90)
>-- J. Gregory Noel, UNIX Guru greg@noel.cts.com or greg@noel.uucp > >____________________ >(*) Does anybody have a tool that will check formats against the argument >list and vet that the values are OK? I realize that it cannot be done for >the general case, but even something that handled the simple cases (fixed >format string, no calculations in arguments) would be useful. In fact, I'd >like to see this as something that the Manx compiler offered; it would >already have the modes of the arguments and it wouldn't be too hard to scan >the format to see if the items matched.... What'd you think, Mike? Fortunately MANX already supports just what you are asking for. Check the 5.0 manual for prototyping. It really does come in handy. -ss -Sullivan Segall _________________________________________________________________ /V\ Sullivan was the first to learn how to jump without moving. ' Is it not proper that the student should surpass the teacher? To Quote the immortal Socrates: "I drank what?" -Sullivan _________________________________________________________________ Mail to: ...sun!portal!cup.portal.com!Sullivan or Sullivan@cup.portal.com
vkr@osupyr.mps.ohio-state.edu (Vidhyanath K. Rao) (03/07/90)
Keith Doyle (keithd@well.sf.ca.us) writes: ->[describes a problem]... causes the display ->to go black (and I mean black. Don't think there is even a vert/horiz ->sync). In article <2090.AA2090@noel> greg@noel.CTS.COM (J. Gregory Noel) writes: ->...but I have ->seen the symptoms he described too many times and I'd like to know how ->to fix it. I have a program that will run under SDB just fine for several ->times, but if I load it under SDB one time too many, the screen goes ->completely black as described above. The only cure is a reboot. -> ->For what it's worth, it's my feeling that the problem is not with SDB per ->se, but that SDB does something that tickles the problem area. It's my ->guess that my program has an errant pointer somewhere that is smashing some ->DOS structure and that when SDB tries to set up its windows, something ends ->up wandering off into never-never land. Why it would only be SDB that ->tickles the problem (the program seems to run just fine as long as I never ->use SDB, which is kind of difficult if I'm doing any debugging) I don't ->know. I had problems when trying to debug the optimised code: With all the possible optimisations turned on, SDB would crash, but the program ran fine if run directly. SDB would work fine with no optimisations. But when the "-so" option was used, SDB would either crash before doing anything, or at the first "t" or "s" command.-- It is the man, not the method, that Nath solves the problem. vkr@osupyr.mps.ohio-state.edu -Poincare. (614)-366-9341
greg@noel.CTS.COM (J. Gregory Noel) (03/07/90)
Keith Doyle (keithd@well.sf.ca.us) writes: ->[describes a problem]... causes the display ->to go black (and I mean black. Don't think there is even a vert/horiz ->sync). I write: ->...but I have ->seen the symptoms he described too many times and I'd like to know how ->to fix it. I have a program that will run under SDB just fine for several ->times, but if I load it under SDB one time too many, the screen goes ->completely black as described above. The only cure is a reboot. Vidhyanath K. Rao (vkr@cis.ohio-state.edu) writes: >I had problems when trying to debug the optimised code: With all the possible >optimisations turned on, SDB would crash, but the program ran fine if run >directly. SDB would work fine with no optimisations. But when the "-so" >option was used, SDB would either crash before doing anything, or at the >first "t" or "s" command.-- This isn't it. I've also had problems debuging optimized code, but at least the manual documents it as a potential problem area, so when I had problems with optimized code, I'd try it unoptimized. But in the case I'm describing, I didn't even recompile the code, just ran SDB on the same binary I had been debugging before. In fact, the way I discovered the problem was by noticing that every time I ran a particular program before running SDB, SDB would crash even before displaying the initial screen. When I would test that program under SDB (with optimization on or off, it didn't seem to matter) I could test it some random number of times and then the screen would go dark as SDB loaded. The program that causes the problem doesn't do anything exciting, only uses stdio.h for I/O, malloc()s only a small amount of storage, checks the return from all resource allocations, returns all resources exactly once, and doesn't have any stray pointers I can find, so I'm stumped. -- -- J. Gregory Noel, UNIX Guru greg@noel.cts.com or greg@noel.uucp
greg@noel.CTS.COM (J. Gregory Noel) (03/07/90)
I write: >(*) Does anybody have a tool that will check formats against the argument >list and vet that the values are OK? .... Sullivan Segall (Sullivan@cup.portal.com) replies: >Fortunately MANX already supports just what you are asking for. Check >the 5.0 manual for prototyping. It really does come in handy. -ss Er, no, I already compile with prototype checking turned on to its maximum extent. I was asking about something that would check for: .... float foo; printf("The value of foo is %ld\n", foo); .... which is clearly incorrect, but not caught by any form of prototype checking that I'm aware of.... -- -- J. Gregory Noel, UNIX Guru greg@noel.cts.com or greg@noel.uucp
ahh@glyph.UUCP (Andy Heffernan) (03/08/90)
In article <34700001@suna8> martin@suna8.cs.uiuc.edu writes: [...] > >P.S. I found what appears to be a bug in Rob Peck's book "Programmer's > Guide to the Amiga". On page 17, he has a sample program that opens > the console and writes 'hello world' using a FileHandle, and fprintf(). > Naively, I tried it and got a requester. Intuitively, it shouldn't > work anyway, since fprintf() needs a (FILE *), and the pointer is a > (FileHandle *). Anyway, just thought you'd like to know... I don't have Rob's book, but it sounds like he's using the fprintf() from amiga.lib (not lc.lib) which understands AmigaDOS file handles. Try linking with just amiga.lib, omitting whatever c-lib comes with your compiler. With Lattice version 5, something like this seems to work for me: 1> lc -v -b0 hello.c 1> blink lib:astartup.obj,hello.o to hello lib lib:amiga.lib Of course, Open() returns a BPTR to a struct FileHandle, not a machine pointer, so using it as or casting to a struct FileHandle is somewhat pointless without BADDR()'ing the returned value from Open() and only if you really want to goop around with FileHandle internals. But what do I know. -- ------------------------------------------------------------------------- Andy Heffernan uunet!glyph!ahh "In a daze, Buck clutched at his head. 'Oh, how manly I feel,' he moaned."
keithd@well.sf.ca.us (Keith Doyle) (03/09/90)
In article <34700001@suna8> martin@suna8.cs.uiuc.edu writes: > I tried your program on my machine (2000HD, 1Meg, 1Meg-Fat Agnus), > and sdb performed just as you described. Quite strange! > > Please post any information you get from MANX about this problem! I > was upset enough that the upgrade didn't include a window to dynamically > observe variables like I have at work on IBM's running Turbo-C or > Zortech-C++! Now it appears that sdb needs further debugging itself! Thanks for trying it out and confirming the bug (thanks to the rest of the gang who did as well). I haven't heard from Manx yet, I feel better now about giving them another call now that I know it is repeatable. This bug does seem serious enough to render SDB's use dicey at best, though I have been able to use it ok by avoiding doing a 't' command over strcpy(), strcat(), etc. I'll let you know if I find out any more. Keith well!keithd