Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#256 closed bug (invalid)

Latest MUI 20.6465 crashs YAM & Odyssey in String_Dispatcher()

Reported by: Guillaume Boesel Owned by:
Priority: normal Milestone: 4.0-2015R3
Component: String.mui Version: 4.0-nightly build
Severity: minor Keywords:
Cc: OS Platform: AmigaOS4
Blocked By: Blocking:
Release Notes:

Description

Summary

Installed latest nighty build (MUI 6465 / MUI-4.0-20150917r4947-os4.lha)
Odyssey & YAM crashs in String_Dispatcher().
No problem on some others MUI programs (example, SysMon)

Steps to reproduce

  1. install latest build and start YAM or Odyssey

Reverted back to MUI 20.6421 fixed this issue.

See YAM crashlog attached

Thank you

Attachments (3)

Crashlog_YAM_2015-09-17_07-54-08.txt (37.7 KB) - added by Guillaume Boesel 4 years ago.
Crashlog_SysMon_2015-09-19_10-13-34.txt (35.5 KB) - added by Guillaume Boesel 4 years ago.
Crashlog_Odyssey_2015-09-19_10-13-33.txt (37.3 KB) - added by Guillaume Boesel 4 years ago.

Download all attachments as: .zip

Change History (20)

Changed 4 years ago by Guillaume Boesel

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

Since you are using the nightly builds please try to identify the last working nightly build instead of refering the 2015R2 release as last working one. There have been lots of changes since the 2015R2 release and if there is really a new bug it must have crept in recently.

All recent nightly builds are available here: http://nightly.muidev.de/

comment:2 Changed 4 years ago by Guillaume Boesel

I can say that it worked at least with 20.6445 (http://muidev.de/ticket/242)

Does YAM & Odyssey work on your OS4 system ?

"All recent nightly builds are available here: ​http://nightly.muidev.de/"
OK, I will try this evening starting from 20.6445 but what is the date of this 6445 build ?

Thank you

comment:3 in reply to:  2 Changed 4 years ago by Thore Böckelmann

Replying to zzd10h:

Does YAM & Odyssey work on your OS4 system ?

I did not yet have the time to check myself on AmigaOS4.

"All recent nightly builds are available here: ​http://nightly.muidev.de/"

OK, I will try this evening starting from 20.6445 but what is the date of this 6445 build ?

That's the nightly build of August 19th. There have been 16 further nightly builds since then. Perhaps you try a binary search like approach to find the guilty build. This will take no more than 4 tries, perhaps 5.

comment:4 Changed 4 years ago by Guillaume Boesel

Found the culprit build, the 15 september one.

Build from 14 september is OK (muimaster 20.6461)

Since build from 15 september (muimaster 20.6462), String_Dispatcher() crashs (to be sure, I tested build from 16 and 17 september too).

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

Thanks for checking. There was only a single relevant change on that day, so the cause is easy to find. I just have to find out why it is causing trouble at all, and why only you are facing the problems.

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

In 4950:

  • String.c: added the usual check for a valid window object before adding the eventhandler. At least this was the location of the crash reported in #256 although it is quite puzzling why this didn't cause any trouble all the years before. This refs #256.

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

Your crashlog pointed to the location where the eventhandler was added unconditionally and the crash definitely happened due to a NULL pointer access. This is the only reason I can think of right now.

The "relevant" change I was talking about was the addition of the MUIA_MinWidth/Height attributes, which cannot be responsible for the crash.

Please try again with the next nightly build and report back.

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

For me everything is working now. I am posting this comment with Odyssey and my private build of the upcoming nightly build. However, I didn't test with earlier nightly builds yet.

comment:9 Changed 4 years ago by Guillaume Boesel

Good, I will test tomorrow with 19 september nighty build.

By curiosity, I tested the today nighty build (20.6466), still the same crash.

comment:10 Changed 4 years ago by Guillaume Boesel

Tested the latest build (muimaster 20.6467) Odyssey stills crash but not in String_Dispatcher().
Now it seems to be in [Title.c:1208] m_Title_Setup().

My own MUI app, SysMon crashs now too in the same function, [Title.c:1208] m_Title_Setup().

I noticed that SysMon crashed too with your latest builds in this function when Odyssey crashed in String_Dispatcher(). SysMon started to crash AFTER 20150917 build.
Therefore, this time maybe something was added after MUI 6465 / MUI-4.0-20150917r4947-os4.lha ?

Last edited 4 years ago by Guillaume Boesel (previous) (diff)

Changed 4 years ago by Guillaume Boesel

Changed 4 years ago by Guillaume Boesel

comment:11 Changed 4 years ago by Guillaume Boesel

Another french user tested the latest build and for him (Pseudaxos) all works as espected. No YAM/Odyssey or SysMon crash.

http://www.amiga-ng.org/viewtopic.php?topic=2165&forum=4

I will try under OS4.1.6…

Nevertheless, he encounters too the locked "MUI:Images/default_OS4/smallerw.png" problem during installation that I reported some times ago (still present for me too).



comment:12 Changed 4 years ago by Guillaume Boesel

Issue solved, I reinstalled MUI in a new drawer and simply copy my extra Libs/ in this new drawer.

Reboot and OK !

Regarding smallerw.png, I had a MUI program at startup (my own FastNote that Pseudaxos uses too) by removing it, installer runs well.
Strangely, I don't use smallerw.png in SysMon and FastNote but starting these program lock this picture file.

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

Priority: undecidednormal
Resolution: invalid
Status: newclosed

Good to hear the solution was so simple.

Regarding the unreplaceable smallerw.png image, how did you install the recent MUI updates? Did you use the Installer script or did you copy them manually?

Note that the supplied FlushMUI tool will try to terminate all running MUI applications for expunging all MUI libraries from memory. If this succeeds then any pending lock on image files will be released as well, provided they are not locked by other non-MUI tasks.

comment:14 Changed 4 years ago by Guillaume Boesel

I always install MUI updates with the embedded installer.
When i start your installer, FlushMUI seems to be well executed, existing MUI applications are closed (Odyssey or SysMon) but not all MUI applications. For example, FastNote is a MUI program based on BWin.mcc class. FlushMUI have no effect on it.

Could it be the use of BWin.mcc that avoid FlushMUI to kill it ? (I know that BWin.mcc is not part of your MUI ;) )

Thank you

comment:15 in reply to:  14 Changed 4 years ago by Thore Böckelmann

Replying to zzd10h:

I always install MUI updates with the embedded installer.
When i start your installer, FlushMUI seems to be well executed, existing MUI applications are closed (Odyssey or SysMon) but not all MUI applications. For example, FastNote is a MUI program based on BWin.mcc class. FlushMUI have no effect on it.

If you don't get a warning about unterminated MUI applications from the Installer script, then all instances of Application.mui were disposed successfully, and of course their processes were terminated as well.

AFAIK BWin.mcc is just custom class to provide borderless windows. There is nothing related to MUI's basic application handling. As such it is strange why using BWin.mcc should make it impossible to terminate an application by letting its MUIM_Application_NewInput method return the typical MUIV_Application_ReturnID_Quit value.

comment:16 Changed 4 years ago by Guillaume Boesel

Yes, I have the warning about MUI applications still running.

I'm very sorry, I found my mistake. To disallow the closure of FastNote by Escape key, I inhibited the MUIV_Application_ReturnID_Quit event…
I reenabled it by default and now this BWin.mcc program is well terminated with FlushMUI.

Sorry for the waste of time (again)…

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

Milestone: future release4.0-2015R3
Note: See TracTickets for help on using tickets.