Opened 4 years ago

Last modified 2 weeks ago

#194 new bug

MCC Calendar 18.3 crash under MUI4

Reported by: Samir Hawamdeh Owned by:
Priority: undecided Milestone:
Component: foreign class Version: 4.0-nightly build
Severity: minor Keywords:
Cc: OS Platform: AmigaOS4
Blocked By: Blocking:
Release Notes:

Description

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 !

Attachments (6)

Crashlog_MUI_2015-04-11_13-38-20.txt (27.1 KB) - added by Samir Hawamdeh 4 years ago.
calendar-hits.txt (2.3 KB) - added by Mikhail Malyshev 3 years ago.
crash.png (811.1 KB) - added by Samir Hawamdeh 2 years ago.
Crashlog_MUI_2016-08-19_14-04-32.txt (28.1 KB) - added by Samir Hawamdeh 2 years ago.
Crashlog_MUI_2016-09-06_02-14-26.txt (25.8 KB) - added by Samir Hawamdeh 2 years ago.
Crash with MUI 5.0 SVN r5515
Crashlog_MUI_2018-10-31_22-43-24.txt (36.0 KB) - added by Hubert Maier 3 weeks ago.
Crash with MCC Calendar and MUI 2018-r2 (r6306)

Download all attachments as: .zip

Change History (28)

Changed 4 years ago by Samir Hawamdeh

comment:1 Changed 4 years ago by Thore Böckelmann

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.

comment:2 Changed 4 years ago by Samir Hawamdeh

@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 :-)

comment:3 Changed 4 years ago by Thore Böckelmann

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…

comment:4 Changed 4 years ago by Samir Hawamdeh

@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 ..

comment:5 Changed 4 years ago by Thore Böckelmann

Any news regarding an answer from Alfonso?

comment:6 Changed 4 years ago by Samir Hawamdeh

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

comment:7 Changed 3 years ago by Thore Böckelmann

Any progress on this topic?

comment:8 Changed 3 years ago by Samir Hawamdeh

Still no … he didn't replied :-/

Changed 3 years ago by Mikhail Malyshev

Attachment: calendar-hits.txt added

comment:9 Changed 3 years ago by Mikhail Malyshev

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

comment:10 Changed 2 years ago by Thore Böckelmann

In 5500:

  • String.c: fixed a possible NULL pointer access. This refs #194.

comment:11 Changed 2 years ago by Thore Böckelmann

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

comment:12 Changed 2 years ago by Samir Hawamdeh

@Thore

Tested today under MUI4 SVN-r5500 … but apparently the problem still present

comment:13 Changed 2 years ago by Thore Böckelmann

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.

comment:14 Changed 2 years ago by Samir Hawamdeh

Ok, crashlog and a grab attached aswell

Changed 2 years ago by Samir Hawamdeh

Attachment: crash.png added

Changed 2 years ago by Samir Hawamdeh

comment:15 Changed 2 years ago by Thore Böckelmann

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.

Changed 2 years ago by Samir Hawamdeh

Crash with MUI 5.0 SVN r5515

comment:16 Changed 2 years ago by Samir Hawamdeh

Tested but apparently nothing changed, see crashlog above

comment:17 Changed 3 weeks ago by Hubert Maier

Not sure if this is of any help, but here is a crashlog with 2018-r2 and MCC Calendar.

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

Changed 3 weeks ago by Hubert Maier

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

comment:18 Changed 3 weeks ago by Samir Hawamdeh

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

comment:19 Changed 3 weeks ago by Thore Böckelmann

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.

comment:20 Changed 3 weeks ago by Hubert Maier

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…

Last edited 3 weeks ago by Hubert Maier (previous) (diff)

comment:21 Changed 3 weeks ago by Thore Böckelmann

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.

Last edited 3 weeks ago by Thore Böckelmann (previous) (diff)

comment:22 Changed 2 weeks ago by Hubert Maier

Guess the author dropped out of the amiga game completely

Note: See TracTickets for help on using tickets.