search

amiga-mui / muidev

:mage_man: Magic User Interface (MUI) – Documentation+Releases
http://muidev.de
55 stars 0 forks source link

MCC Calendar 18.3 crash under MUI4 #194

Closed jens-maus closed 3 years ago

jens-maus commented 9 years ago

@samo79 created the issue:

Summary

The old MCC Calendar 18.3 (68k) crash badly under MUI4 (AmigaOS4)

http://aminet.net/package/dev/mui/MCC_Calendar

Steps to reproduce

  1. Just copy the class files
  2. Start MUI and select the class from the prefs

Expected results

Should work :-)

Actual results

It doesn't !

jens-maus commented 9 years ago

@samo79 uploaded file Crashlog_MUI_2015-04-11_13-38-20.txt (27.1 KiB):

jens-maus commented 9 years ago

@tboeckel commented:

Unfortunately I am not able to reproduce this issue, at least no on AmigaOS3. The crashlog just points to 68k code, in contrast to the crashlog from #192. Finally the source code of Calendar.mcc is not available.

As long as these hurdles exist I am affraid I cannot do anything, because I have no clue where to look for a problem.

jens-maus commented 9 years ago

@samo79 commented:

@Thore

Understand, well i might contact Alfonso Ranieri asking for the code .. Aniway don't know if because your previews changes (for the other problematic class i've reported you) but now the crash in this class become skippable .. of course it still the same error as before (when opened in MUI prefs), but more or less the class seems working now :-)

jens-maus commented 9 years ago

@tboeckel commented:

If the crash still occurs then it would be nice to get a new crashlog. Perhaps it looks different to the first one. At least for LayGroup.mcp the log definitely pointed to PPC code which then could be identified very easily.

And please tell me whether you get a reply from Alfonso. I already had contact with him via EMail about 3 years ago. Back then he emerged only when either Jens or me did some changes to his public OpenSource classes which did not fully fit into his MUI4-only world. He then simply reverted lots of our changes without trying to preserve the compatibility to MUI3. After that he crept back under his stone and never did any further work on the classes. Not really a good team player from my point of view...

jens-maus commented 9 years ago

@samo79 commented:

@Thore

If the crash still occurs then it would be nice to get a new crashlog. Perhaps it looks different to the first one.

Crash still exactly the same, just now it's become skippable

And please tell me whether you get a reply from Alfonso. I already had contact with him via EMail about 3 years ago.

I just mailed him, let's see what he say (if he reply)

Back then he emerged only when either Jens or me did some changes to his public OpenSource classes which did not fully fit into his MUI4-only world. He then simply reverted lots of our changes > without trying to preserve the compatibility to MUI3. After that he crept back under his stone and never did any further work on the classes. Not really a good team player from my point of view...

It's the classic attitude of most MorphOS devs, well not that others are so better when we speaking about collaboration .. Aniway after all i hope your changes were preserved ..

jens-maus commented 9 years ago

@tboeckel commented:

Any news regarding an answer from Alfonso?

jens-maus commented 9 years ago

@samo79 commented:

Not yet, he doesn't replied to my mail ... :-/

jens-maus commented 9 years ago

@tboeckel commented:

Any progress on this topic?

jens-maus commented 9 years ago

@samo79 commented:

Still no ... he didn't replied :-/

jens-maus commented 9 years ago

Michael uploaded file calendar-hits.txt (2.3 KiB):

jens-maus commented 9 years ago

Michael commented:

Can confirm that there are problems.

When entering the prefs for Calendar for the first time we get a hit. (MUI4-OS3 nightly)

https://muidev.de/attachment/ticket/194/calendar-hits.txt

jens-maus commented 8 years ago

@tboeckel commented:

In amiga-mui/mui@1178da41e2e3e73423f529f58d865627c5581729:

jens-maus commented 8 years ago

@tboeckel commented:

Please try if the latest change fixes the hits. At least I don't get any hits anymore.

jens-maus commented 8 years ago

@samo79 commented:

@Thore

Tested today under MUI4 SVN-amiga-mui/mui@1178da41e2e3e73423f529f58d865627c5581729 ... but apparently the problem still present

jens-maus commented 8 years ago

@tboeckel commented:

Can you provide a new crashlog please? At least on AmigaOS3 there are no more crashes.

Just for the record, Calendar.mcc never caused immediate crashes for me, but only when I started MUI prefs a second time. The crash finally happened in String.mui in a place which could not really be responsible for a crash. The pointer in question definitely was non-NULL but as soon as the code dereferenced it it did become NULL, no matter how much debug output I added around that place to output the non-NULL value of that pointer. The workaround was to precalculate the obtained value. Then the crash (on AmigaOS3) was gone.

So basically the real bug is still there, most probably in Calendar.mcc, but maybe in MUI.

jens-maus commented 8 years ago

@samo79 commented:

Ok, crashlog and a grab attached aswell

jens-maus commented 8 years ago

@samo79 uploaded file crash.png (811.1 KiB):

crash.png

jens-maus commented 8 years ago

@samo79 uploaded file Crashlog_MUI_2016-08-19_14-04-32.txt (28.1 KiB):

jens-maus commented 8 years ago

@tboeckel commented:

Probably this issue has exactly the same reason as #307 and #309. If I guessed right this might be fixed with the next nightly build of both MUI4 and MUI5. Please check again with that version.

jens-maus commented 8 years ago

@samo79 uploaded file Crashlog_MUI_2016-09-06_02-14-26.txt (25.8 KiB):

Crash with MUI 5.0 SVN r5515

jens-maus commented 8 years ago

@samo79 commented:

Tested but apparently nothing changed, see crashlog above

jens-maus commented 5 years ago

@raziel- commented:

Not sure if this is of any help, but here is a crashlog with 2018-amiga-mui/mui@babb36478f8492771a105eb3e147cf32d7f9abf4 and MCC Calendar.

It happens when one clicks on "Calendar" in MUI prefs after clicking "More"

jens-maus commented 5 years ago

@raziel- uploaded file Crashlog_MUI_2018-10-31_22-43-24.txt (36.0 KiB):

Crash with MCC Calendar and MUI 2018-r2 (r6306)

jens-maus commented 5 years ago

@samo79 commented:

Yep it's the same kind of crash reported years ago and it's always reproducible with the same steps, until now problem still without solution .. however luckly it's harmeless and doesn't prevent the use of the class

jens-maus commented 5 years ago

@tboeckel commented:

Thanks for the new crashlog, but unfortunately it does not contain any new information.

Basically all crashlogs look the same: the crash happens in invalid memory regions, at least according to the 68k disassembly.

The next illogical thing is the way of the code to the final crash. This is the stack trace in reversed order (oldest call at the top):

First MUI does some internal stuff, most probably some DoMethod() or DoSuperMethod() call, which ends up in intuition.library:

5bfad0a4 - "LIBS:muimaster.library" Hunk 0004 Offset 00000264 (SegList: 16e54429)7f70f77c - "LIBS:muimaster.library" Hunk 0005 Offset 0003777c (SegList: 16e54429)02195eac - "intuition.library.kmod" Hunk 0000 Offset 0000a2ac021ad048 - "intuition.library.kmod" Hunk 0000 Offset 00021448

Back to MUI, perhaps some basic graphic rendering:

7f6db27c - "LIBS:muimaster.library" Hunk 0005 Offset 0000327c (SegList: 16e54429)02b30000 - "graphics.library.kmod" Hunk 0001 Offset 0000174002b30000 - "graphics.library.kmod" Hunk 0001 Offset 00001740

Since graphics.library is performing a DoMethod() call this could be a backfill hook:

02195eac - "intuition.library.kmod" Hunk 0000 Offset 0000a2ac021ad048 - "intuition.library.kmod" Hunk 0000 Offset 000214487f6db27c - "LIBS:muimaster.library" Hunk 0005 Offset 0000327c (SegList: 16e54429)7f73eed0 - "LIBS:muimaster.library" Hunk 0005 Offset 00066ed0 (SegList: 16e54429)02b30000 - "graphics.library.kmod" Hunk 0001 Offset 00001740

Now it becomes weird, why should graphics.library call code of Calendar.mcp directly? This is something that MUI must do:

5b47f936 - "LIBS:mui/Calendar.mcp" Hunk 0000 Offset 00002936 (SegList: 16d1f401)

And here it eventually crashes:

02948a74 (68k IP) - "kernel" Hunk 0001 Offset 00018a74

I'd guess there happens some memory trashing of code and hence the crash happens in invalid memory. At least for me this is the only explanation for such a weird stack trace with an illogical code path.

There is nothing I can do against this without access to the original code. Only the code can reveal what is done wrong here.

jens-maus commented 5 years ago

@raziel- commented:

Maybe the original author mixed some direct calls with MUI ones (because back when he created this .mcc some of the calls aren't there?) which worked back then, but does crash now?

@Samir

Any chance getting in touch with Alfonso?

@Thore

Maybe it would be best to mark this .mcc incomliant and let the next MUI version refuse to install/use it? As long as you can't secure the source that is.

EDIT: I started a thread over at aw.net to try and find him...

jens-maus commented 5 years ago

@tboeckel commented:

I will not add some kind of blacklist to exclude certain classes from being used. MUI cannot (yet) be made responsible for the crash. There are lots of buggy classes out there. Lots of applications might cease to work if the usage of (possibly) buggy classes is forbidden. I don't need this kind of negative comments, which will definitely follow if I implement something like this. If people install buggy stuff, then it is their task to accept the consequences.

Furthermore, as far as I can see it, only Calendar.mcp (the prefs module) causes issues, while Calendar.mcc (the class used by applications) works fine. So if the crash is really causing head aches for certain people and the chance to activate the prefs page of Calendar class is too big, then one can remove/rename Calendar.mcp and keep Calendar.mcc in place. The class itself will continue to work, you just won't be able to modify its settings.

jens-maus commented 5 years ago

@raziel- commented:

Guess the author dropped out of the amiga game completely

jens-maus commented 5 years ago

@samo79 commented:

@Thore

I have a good news, finally i was able to reach the author and he promise to me the source of this class along with other important sources :-)

jens-maus commented 5 years ago

@tboeckel commented:

That's really great news. If we really get the source code this could be something to provide as a public example MCC with MUI's SDK.

jens-maus commented 5 years ago

@tboeckel commented:

Any news on your investigation?

jens-maus commented 5 years ago

@samo79 commented:

Unfortunely not yet, but today i sent to him another mail so i'm still patiently waiting ... he promised me the source code for this class and also other interesting sources

jens-maus commented 5 years ago

@tboeckel commented:

Any reaction from Alfonso?

jens-maus commented 5 years ago

@samo79 commented:

Not yet ... probably i'll send him another remind

jens-maus commented 5 years ago

@tboeckel commented:

Any news here?

jens-maus commented 5 years ago

@samo79 commented:

Still no news ... Alfie never responded

jens-maus commented 4 years ago

@tboeckel commented:

I guess you still got no reply, correct?

jens-maus commented 4 years ago

@samo79 commented:

Ah, thanks for remind just forgot so did non (re)tried :-) I will retry this evening or tomorrow

jens-maus commented 4 years ago

@tboeckel commented:

Tomorrow is two months ago by now. Any news?

jens-maus commented 3 years ago

@tboeckel changed status from new to closed

jens-maus commented 3 years ago

@tboeckel set resolution to wontfix

jens-maus commented 3 years ago

@tboeckel commented:

I think we can consider this issue as unresolveable since the original author cannot be contacted anymore. Without his help there is nothing I can do about this.

jens-maus commented 3 years ago

@samo79 commented:

Hey ..for the strangeness of things he replayed me 1 week ago telling me that due to a manual error he had mistakenly deleted some files .. but he promised me to check and eventually rebuild everything and then provide us the source we need .. I think we may give him another chance letting this ticket opened some more ..

jens-maus commented 3 years ago

@tboeckel commented:

We can reopen this ticket as soon as there is real progress happening.