rbabel@babylon.rmt.sub.org (Ralph Babel) (01/22/91)
In article <91022.110834GHGAQA4@cc1.kuleuven.ac.be> GHGAQA4@cc1.kuleuven.ac.be (Tyberghein Jorrit) writes: > I have AmigaDOS 2.04 and I discovered some alarming bugs : We'll see about that ... > The list of locks for the RAM disk is corrupt (my debugger > and Xoper crash when they try to list them). This was not > the case in AmigaDOS 2.02. The content of fl_Link in case of volumes that are currently mounted is undefined. Since the RAM disk doesn't support removable media (otherwise it would have to generate a DISKREMOVED event when a RAM expansion is taken out of the machine :-), there can't be a RAM disk volume with outstanding (i.e. linked) locks. > Some processes (like DF0, RAM, WB_2.x, HARD) all have a > corrupt process seglist. Again my debugger and Xoper give > wrong information when trying to look at these. This was > also not the case in AmigaDOS 2.02. All these process have > something to do with disk devices. Could this be the > problem ? Even though the contents of pr_SegList indeed appear to be a bit messed up (Randell?), again the real problem is in relying on undocumented side-effects. In case of GlobVec==0, DeviceProc()/LoadDevice() require pr_SegList (really: SegArray) to inherit global vector addresses both from the DOS kernel and the application (good old BCPL loader-format - those who have written handlers before 1.2 know what I'm talking about :-). BCPL is (almost) history, so don't count on all that undocumented magic. Ralph
GHGAQA4@cc1.kuleuven.ac.be (Tyberghein Jorrit) (01/22/91)
Hi,
I have AmigaDOS 2.04 and I discovered some alarming bugs :
The list of locks for the RAM disk is corrupt (my debugger
and Xoper crash when they try to list them). This was not
the case in AmigaDOS 2.02.
Some processes (like DF0, RAM, WB_2.x, HARD) all have
a corrupt process seglist. Again my debugger and Xoper
give wrong information when trying to look at these.
This was also not the case in AmigaDOS 2.02.
All these process have something to do with disk devices.
Could this be the problem ?
The SetFont cli command always looses memory. Even if
you give no arguments to SetFont.
You loose memory when you try 'avail flush' from the
'execute command' workbench menu item.
Jorrit Tybergheinjesup@cbmvax.commodore.com (Randell Jesup) (01/23/91)
In article <91022.110834GHGAQA4@cc1.kuleuven.ac.be> GHGAQA4@cc1.kuleuven.ac.be (Tyberghein Jorrit) writes: > I have AmigaDOS 2.04 and I discovered some alarming bugs : Interesting, since we've never released anything called 2.04 yet. We have sent to developers who signed non-disclosure statements copies of the latest beta kickstart (36.314). Bug reports should always include kickstart and workbench revision numbers, and should be submitted through normal channels (bugs@cbmvax.commodore.com, on BIX in amiga.com/bug.reports or amiga.cert/bug.reports, adsp groups or support managers in europe or physical mail). Posting them here may or may not get them into our database. If you are not a registered developer and was not sent the kickstart by Commodore, what are you doing with it? Such things are not for general distribution, and with good reasons. > The list of locks for the RAM disk is corrupt (my debugger > and Xoper crash when they try to list them). This was not > the case in AmigaDOS 2.02. This seems strange. 2.00/2.01 ramdisk used CPTR's instead of BPTR's for chaining locks, but as of 2.02 (I think), we went back to BPTR's to keep some debugging utilities from breaking. BTW, using those pointers is at least theoretically illegal, since there's no way to keep it from changing out from under your access of it, but it's nice to keep debuggers from breaking any worse than they are now. I'll pull down the latest Xoper (since you didn't give a rev number I have no idea which one you used) and try it. > Some processes (like DF0, RAM, WB_2.x, HARD) all have > a corrupt process seglist. Again my debugger and Xoper > give wrong information when trying to look at these. > This was also not the case in AmigaDOS 2.02. They look fine to me (looking at them directly in wack). You didn't say how they were corrupted. Don't get me wrong, bug reports are quite useful if they include enough information to handle them. However, they must include that information, and be sent to right place. Also, betatest kickstarts should not travel outside people they're supposed to go to. They may have bugs that we would not allow in releases to users, etc, etc. They confuse the issue of supporting users (witness people who've been bitten by running pre-release versions of 1.3 and FFS for years after 1.3 was actually released). Our developers sign non-disclosure forms to cover things we send them, and should try to live up to that agreement. I noticed this message, and will look into some of the things mentioned here, but that's no guarantee that I will do so for all messages here. Use the bug-reporting channels mentioned above. Remember that my presence here is not official nor required. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
chucks@pnet51.orb.mn.org (Erik Funkenbusch) (01/26/91)
jesup@cbmvax.commodore.com (Randell Jesup) writes: >In article <91022.110834GHGAQA4@cc1.kuleuven.ac.be> GHGAQA4@cc1.kuleuven.ac.be (Tyberghein Jorrit) writes: >> I have AmigaDOS 2.04 and I discovered some alarming bugs : > > Interesting, since we've never released anything called 2.04 yet. >We have sent to developers who signed non-disclosure statements copies of >the latest beta kickstart (36.314). Bug reports should always include >kickstart and workbench revision numbers, and should be submitted through >normal channels (bugs@cbmvax.commodore.com, on BIX in amiga.com/bug.reports >or amiga.cert/bug.reports, adsp groups or support managers in europe or >physical mail). Posting them here may or may not get them into our database. >If you are not a registered developer and was not sent the kickstart by >Commodore, what are you doing with it? Such things are not for general >distribution, and with good reasons. > >> The list of locks for the RAM disk is corrupt (my debugger >> and Xoper crash when they try to list them). This was not >> the case in AmigaDOS 2.02. > > This seems strange. 2.00/2.01 ramdisk used CPTR's instead of BPTR's >for chaining locks, but as of 2.02 (I think), we went back to BPTR's to keep >some debugging utilities from breaking. BTW, using those pointers is at >least theoretically illegal, since there's no way to keep it from changing >out from under your access of it, but it's nice to keep debuggers from >breaking any worse than they are now. I'll pull down the latest Xoper >(since you didn't give a rev number I have no idea which one you used) and >try it. > >> Some processes (like DF0, RAM, WB_2.x, HARD) all have >> a corrupt process seglist. Again my debugger and Xoper >> give wrong information when trying to look at these. >> This was also not the case in AmigaDOS 2.02. > > They look fine to me (looking at them directly in wack). You didn't >say how they were corrupted. > > Don't get me wrong, bug reports are quite useful if they include >enough information to handle them. However, they must include that >information, and be sent to right place. Also, betatest kickstarts should >not travel outside people they're supposed to go to. They may have bugs that >we would not allow in releases to users, etc, etc. They confuse the issue >of supporting users (witness people who've been bitten by running pre-release >versions of 1.3 and FFS for years after 1.3 was actually released). Our >developers sign non-disclosure forms to cover things we send them, and should >try to live up to that agreement. I noticed this message, and will look >into some of the things mentioned here, but that's no guarantee that I will >do so for all messages here. Use the bug-reporting channels mentioned above. >Remember that my presence here is not official nor required. > >-- >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. >{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup >The compiler runs >Like a swift-flowing river >I wait in silence. (From "The Zen of Programming") ;-) This brings to mind a question. Is it allowed for a developer who has signed a non-disclosure to allow others to use his machine with the beta? or just not for them to give it or any support documentation or files out? I ask this because i developer friend has allowed me to test several things under his beta. if this is not allowed i will discontinue, but I was just curious. any help as of what is and is not allowed would be appreciated. UUCP: {amdahl!bungia, crash}!orbit!pnet51!chucks ARPA: crash!orbit!pnet51!chucks@nosc.mil INET: chucks@pnet51.orb.mn.org