jens-maus / yam

:mailbox_with_mail: YAM (short for 'Yet Another Mailer') is a MIME-compliant open-source Internet email client written for Amiga-based computer systems (AmigaOS4, AmigaOS3, MorphOS, AROS). It supports POP3, SMTP, TLSv1/SSLv3 connection security, multiple users, multiple identities, PGPv2/v5 encryption, unlimited hierarchical folders, an ARexx interface, etc...
https://yam.ch
GNU General Public License v2.0
61 stars 18 forks source link

Illegal memory accesses on startup with unreachable paths #661

Closed tac1ica closed 7 years ago

tac1ica commented 7 years ago

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

  1. Install YAM, run it, then exit. Notice that the install path is written to the config file.
  2. Rename the volume where YAM is installed, e.g. from "Work" to "Work2".
  3. Run YAM again.
  4. On startup, YAM will complain that it couldn't write to file "/YAM/.config". As expected, it also fails to create the default mail folders.

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

tboeckel commented 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.

tac1ica commented 7 years ago

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.

hits.txt debug2.txt

tac1ica commented 7 years ago

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.

tboeckel commented 7 years ago

If you want to comment on a specific issue then please do it there instead of replying to a completely unrelated issue.

tboeckel commented 7 years ago

Please try to reproduce this issue with the next nightly build of YAM 2.10-dev.

tboeckel commented 7 years ago

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.

tac1ica commented 7 years ago

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.

tboeckel commented 7 years ago

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?

tac1ica commented 7 years ago

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.

tboeckel commented 7 years ago

Nightly builds are working again and an updated build is online already.

tac1ica commented 7 years ago

Yep, I can confirm the hits are now gone. Good job. :+1: