Forum unknown
· Programming
#Modula-2 bug
21 messages in this thread
Very often I experience that when the compiler displays the End of
Compilation message, the time is changed/stopped (I run one of these small
title bar clocks). At one time I also experienced a wipeout of an entire
index track with the object file. A dangling pointer problem it seems. Has
anyone experienced similar problems ?
Phew!!!!! And I was beginning to think that there was something wrong with
the clock hardware on my Amy! Yup, this has happened to me on numerous
occasions. That is, the system clock got trashed. I don't know what you
mean by index track. You mean the compiler trashed the directory of your
disk??? If that's the case, then OH OH!!! Time to make backups! – Steve
The DSKSLV program in DL6 (I think) is indispensable. I don't think that it
is the M2 compiler which has caused all my disk problems. I do not have a
high degree of confidence in the Amiga file system. The DSKSLV program
reports link errors (resolvable, though) on disks which hardly have been
used after last DSKSLV on them. It is comforting, though, that a lot of
redundant information can make programs like DSKSLV save most (not all!) of
a disk.
Hmmm. I've managed to crash disks before, but that was always because I
met the Guru while doing disk access. Never happened to me when everything
else seemed normal. DiskDoctor on the 1.2 release ain't bad either. –
Steve –
Hmmm. I've managed to crash disks before, but that was always because I
met the Guru while doing disk access. Never happened to me when everything
else seemed normal. DiskDoctor on the 1.2 release ain't bad either. –
Steve –
Joergen I too have had problems during compiles. I have lost whole disks
that were only partially recoverable. There were not only link errors, but
also wiped sections of the files. Originally I thought that this only
occurred when I did not close a loop, or missed the period at the EOF.
However I have since found that the system will sometimes lock, and trash
my files even upon sucesscul compilation. Sometimes I can boot, compile
and lock and then reboot and get away clean. That is STRANGE! Nowadays I
copy my source to ram: and do the compiles there so that I don't loose my
sources.
Joergen I too have had problems during compiles. I have lost whole disks
that were only partially recoverable. There were not only link errors, but
also wiped sections of the files. Originally I thought that this only
occurred when I did not close a loop, or missed the period at the EOF.
However I have since found that the system will sometimes lock, and trash
my files even upon sucesscul compilation. Sometimes I can boot, compile
and lock and then reboot and get away clean. That is STRANGE! Nowadays I
copy my source to ram: and do the compiles there so that I don't loose my
sources.
The DSKSLV program in DL6 (I think) is indispensable. I don't think that it
is the M2 compiler which has caused all my disk problems. I do not have a
high degree of confidence in the Amiga file system. The DSKSLV program
reports link errors (resolvable, though) on disks which hardly have been
used after last DSKSLV on them. It is comforting, though, that a lot of
redundant information can make programs like DSKSLV save most (not all!) of
a disk.
Phew!!!!! And I was beginning to think that there was something wrong with
the clock hardware on my Amy! Yup, this has happened to me on numerous
occasions. That is, the system clock got trashed. I don't know what you
mean by index track. You mean the compiler trashed the directory of your
disk??? If that's the case, then OH OH!!! Time to make backups! – Steve
Yes, I just noticed the stopped clock problem myself. A make routine
written in Modula-2 that I'm porting to the Amiga didn't seem to do the
right thing. After some detective work I found that the TDI compiler stops
the clock. This doesn't happen on every source file compile but the
simplest case I've found is to just ask it to compile a non existent file
and then hit return when it prompts for a file name.
Les Caudle, do you know about this bug?
Tom
Yes, I just noticed the stopped clock problem myself. A make routine
written in Modula-2 that I'm porting to the Amiga didn't seem to do the
right thing. After some detective work I found that the TDI compiler stops
the clock. This doesn't happen on every source file compile but the
simplest case I've found is to just ask it to compile a non existent file
and then hit return when it prompts for a file name.
Les Caudle, do you know about this bug?
Tom
Yeah, I saw the TDI modula compiler trash the clock. Maybe it's so fast it
runs backwards in time ! (Just kidding). As for disks, I haven't
experienced any problems. However, I crashed the Amiga during compilation
if there wasn't enough room for the code file on my disk……Richie
Well, in my case I certainly did not meet the Guru, but after the
compilation an entire track with directory information, including the .lnk
file, was gone. The disk in question was about 95% full, but the module
compiled was no more than 20 lines in size. I do not experience any
problems with the disk drive in general, but when using the DSKSLV program
it displays these bad links (often on Preferences). However, it is able to
recover the file anyway. Have you tried using DSKSLV on any of your
supposedly good disks ?
You mean that when you run DskSlv on an apparently good disks you get the
displayu of bad links? I think that this is normal. The way AmigaDos
works when you create a new file or overwrite an existing one is that it
grabs whatever blocks are marked as available. These blocks were possibly
used previously for a file which doesn't exist anymore, but they may look
to DskSlv as fragments of a file, and that's way you get those msgs. (I
think this is right, but don't take my word for it: I'm extremely tired,
and my mind is not functioning too welllllll) – Steve Zzzzzzzzzz….
The bad links shown by DiskSalv aren't due to the blocks possibly having
been used previously. I'm not sure if this reflects a bug in the DiskSalv
program, but its possible that it does. I haven't found this consistant
enough to pin down, though the program does seem to resolve such problems
correctly. The first pass of DiskSalv scans every entry on the disk, and
reports the contents. Here's where a previously used block might be
reported as "Data" instead of "Unused". The second pass of the program is
the part that looks at links, and it bases these links on file blocks that
it has read. Disk blocks are chained in order, and the entire list of
blocks used in a file are present in the file header and the extension
headers, if required. DiskSalv looks at both pointers for any "next block"
assessment; if they don't match, it looks at both blocks, and checks
various things, like the sequence numbers, the parent blocks, and if each
has previously been tagged as being part of a valid file. This is where a
link mismatch is likely to be reported, though the chance of choosing the
wrong link at this point seems very unlikely.
The bad links shown by DiskSalv aren't due to the blocks possibly having
been used previously. I'm not sure if this reflects a bug in the DiskSalv
program, but its possible that it does. I haven't found this consistant
enough to pin down, though the program does seem to resolve such problems
correctly. The first pass of DiskSalv scans every entry on the disk, and
reports the contents. Here's where a previously used block might be
reported as "Data" instead of "Unused". The second pass of the program is
the part that looks at links, and it bases these links on file blocks that
it has read. Disk blocks are chained in order, and the entire list of
blocks used in a file are present in the file header and the extension
headers, if required. DiskSalv looks at both pointers for any "next block"
assessment; if they don't match, it looks at both blocks, and checks
various things, like the sequence numbers, the parent blocks, and if each
has previously been tagged as being part of a valid file. This is where a
link mismatch is likely to be reported, though the chance of choosing the
wrong link at this point seems very unlikely.
You mean that when you run DskSlv on an apparently good disks you get the
displayu of bad links? I think that this is normal. The way AmigaDos
works when you create a new file or overwrite an existing one is that it
grabs whatever blocks are marked as available. These blocks were possibly
used previously for a file which doesn't exist anymore, but they may look
to DskSlv as fragments of a file, and that's way you get those msgs. (I
think this is right, but don't take my word for it: I'm extremely tired,
and my mind is not functioning too welllllll) – Steve Zzzzzzzzzz….
Well, in my case I certainly did not meet the Guru, but after the
compilation an entire track with directory information, including the .lnk
file, was gone. The disk in question was about 95% full, but the module
compiled was no more than 20 lines in size. I do not experience any
problems with the disk drive in general, but when using the DSKSLV program
it displays these bad links (often on Preferences). However, it is able to
recover the file anyway. Have you tried using DSKSLV on any of your
supposedly good disks ?
Yeah, I saw the TDI modula compiler trash the clock. Maybe it's so fast it
runs backwards in time ! (Just kidding). As for disks, I haven't
experienced any problems. However, I crashed the Amiga during compilation
if there wasn't enough room for the code file on my disk……Richie