Closed tac1ica closed 7 years ago
A crashlog including a stack trace would be nice. A simple disassembly of the crash locations does not help very much. Perhaps you need to use the debug version of YAM, because the normal version does not include debug information to produce a suitable stack trace.
I thought so.
OK, SegTracker wasn't working on this config (instant system freeze), but I managed to run it now after using SetPatch NOROMUPDATE. Attached are the MuForce hits from YAM.debug 68K with SegTracker 37.74 running, and (hopefully) the relevant part taken from the debug output from Sashimi.
BTW, re: bug #662 - burying the PNG_dt requirement notice down in the README file where nobody will read it won't help much. You'd better mention it in the "Requires:" line at the very beginning. Just saying.
If you want to comment on a specific issue then please do it there instead of replying to a completely unrelated issue.
Please try to reproduce this issue with the next nightly build of YAM 2.10-dev.
Unfortunately the changes done do not completely eliminate all illegal accesses. Currently I have no idea what is really causing the accesses. They definitely happen inside NList.mcc when parsing the text to be displayed. I'll have tio investigate further.
The test was done on vanilla OS3.9BB2, thus it also involved plenty of warnings about the infamous missing PNG datatype. For the time being I can't check whether that's related or not because there isn't a newer nightly build to test and anyway I'm in the middle of salvaging 2TB of data before a dying drive says bye bye forever, so no emulation right now. I suggest you defer further investigation until I post again.
MUI classes are up to date though.
I finally found the cause of this issue. When there are no valid folders the main window's mail list's display method did not return proper strings for the list's title. This was causing all the illegal memory accesses.
Once again: if you want to complain about "the infamous missing PNG datatype" then please use the corresponding issue. This one is about illegal memory accesses, not about imagery or PNG files in particular. It should not be that hard to follow some basic rules, shouldn't it?
I wasn't complaining, but just trying to avoid you going on a wild goose chase out of lack of information about the circumstances around the test. I'm sure you wouldn't like to spend your valuable time looking for a problem that could be potentially caused by something totally different. Honestly.
Thank you for the fix.
Nightly builds are working again and an updated build is online already.
Yep, I can confirm the hits are now gone. Good job. :+1:
Submission type
Bug report
YAM version
2.9p1 68k
Used operating system
AmigaOS3/m68k (vanilla 3.9BB2 on latest fs-uae for Linux amd64)
Used Amiga system
Emulated Amiga 4000/040
Expected behaviour you didn't see
Since YAM: is gone, one would expect YAM to use PROGDIR: instead of absolute paths that can later break. This would also enhance portability. Say you want to reformat/replace the drive where YAM is installed -- drag the YAM folder to a new drive and you're good to go. Try that on Windows! :)
Unexpected behaviour you saw
Multiple illegal memory accesses on startup
Steps to reproduce the problem
As those complaints are printed, multiple illegal memory accesses occur. I'm attaching some debug output from the latest MuForce&MGA combo.
yam.debug.txt