Custom Query (444 matches)


Show under each result:

Results (16 - 18 of 444)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Ticket Resolution Summary Owner Reporter
#441 duplicate MUI-5.0-20200620r6570 nightly build crashes when clickin mouse Thore Böckelmann Javier de las Rivas

MUI-5.0-20200620r6570 nightly build crashes when clickin mouse when I'm on a MUI application, YAM, Oddyesey,… Using AOS4FE upd1 (and beta components). I get this crashlog: … [_impl_InitResident] Lamp.mcc V21 initialized [_impl_AddTask] Adding Task 0x5A392070, RANDOM/Random-Handler 52.1 (0x5B715790) [_impl_AddTask] Adding Task 0x5A3921F0, [OWB] IconDatabase (0x5B715890) [_impl_AddTask] Adding Task 0x5A392370, [OWB] JavaScriptCore::BlockFree (0x5B715990) [btpool_arenafree] * Error: Freeing arena 0x5A3948EC from a pool that is not it's owner (in task input.device, owner = 0xFEFEBEEF) [_impl_Alert] Alert (0x0100000F) called from 0x0183654C

Kernel command line: debuglevel=4 SERIAL MUNGE

Registers pointing to code: r0 : native kernel module Kickstart/kernel.debug+0x0003dd68 r3 : native kernel module Kickstart/kernel.debug+0x00007560 r5 : native kernel module Kickstart/kernel.debug+0x009bae14 r6 : native kernel module Kickstart/kernel.debug+0x009bae04 r7 : native kernel module Kickstart/kernel.debug+0x009bae74 r10: module L:Random-Handler at 0x00000001 (section 0 @ 0xFFFFFFDC) r22: native kernel module Kickstart/RadeonHD.chip+0x003fda80 r26: module L:Random-Handler at 0x00000001 (section 0 @ 0xFFFFFFDC) r27: native kernel module Kickstart/kernel.debug+0x00880000 r29: native kernel module Kickstart/kernel.debug+0x009bdcc2 r31: native kernel module Kickstart/kernel.debug+0x008a9be4 ip : native kernel module Kickstart/kernel.debug+0x00007548 lr : native kernel module Kickstart/kernel.debug+0x0003dd70 ctr: native kernel module Kickstart/kernel.debug+0x000004c0

Stack trace: (0x6FE74D30) native kernel module Kickstart/kernel.debug+0x00007548 (0x6FE74D60) native kernel module Kickstart/kernel.debug+0x0003dd70 (0x6FE74D80) native kernel module Kickstart/kernel.debug+0x0003654c (0x6FE74DB0) native kernel module Kickstart/kernel.debug+0x000368f8 (0x6FE74DE0) native kernel module Kickstart/intuition.library.kmod+0x00022eac (0x6FE74E20) native kernel module Kickstart/intuition.library.kmod+0x00023644 (0x6FE74E50) native kernel module Kickstart/input.device.kmod+0x00000a70 (0x6FE74F30) native kernel module Kickstart/input.device.kmod+0x0000261c (0x6FE74FD0) native kernel module Kickstart/kernel.debug+0x0003d1f0

Disassembly of crash site:

01807538: 7C641B78 mr r4,r3 0180753C: 3C600180 lis r3,384 01807540: 60637560 ori r3,r3,30048 01807544: 44000002 sc

01807548: 4E800020 blr

0180754C: 7C641B78 mr r4,r3 01807550: 3C600180 lis r3,384 01807554: 60637688 ori r3,r3,30344 01807558: 44000002 sc 0180755C: 4E800020 blr

Stack pointer (0x6FE74D30) is inside bounds Redzone is OK (4)

68k register dump DATA: 00000001 00000000 00000000 00000000 00000000 00000000 00000000 00000000

ADDR: 6FFA6000 A2564800 00000000 00000000 00000000 00000000 00000000 6FE74250

With previous nighly builds all was correct.

#440 fixed Dangling directory locks when MUI first started Thore Böckelmann Mike Steed


When the first MUI application is started following bootup, it leaves dangling locks on its home directory when the application is later quit, which prevent the directory from being deleted. I don't know if this is a bug or just an aspect of MUI operation. If the latter, it's easily mistaken for a bug.

The scenario is that someone downloads an archive and unpacks it onto the RAM disk in order to evaluate the program. Whether they decide to keep it or not, they eventually will want to delete the drawer on the RAM disk. When they are unable to, it leaves a poor impression as to the quality of the program.

Steps to reproduce

  1. Start with a freshly-booted system, with no MUI applications running.
  1. Open the MUI drawer and drag the Demos drawer to the RAM Disk. Open

the Demos drawer on the RAM Disk.

  1. Run one of the demo programs. It doesn't seem to matter which one-

try Aboutbox. Immediately quit the program.

  1. Close the Demos drawer and try to delete it.

Expected results

The drawer should be deleted.

Actual results

DOS throws an "Object in use" error, and the drawer is not deleted (though all of its contents are).

Running Scout shows two locks remaining on the Demos drawer, which is what prevents it from being deleted.


The dangling locks only appear the first time a MUI application is run after booting. Running that demo or another afterwards does not add any additional locks.

If Scout — itself a MUI application — is run prior to running a demo program, then everything works fine- there are no dangling locks, and the Demos drawer can be deleted. Of course, Scout's home directory may then get the dangling locks, but there's no easy way to tell.

Some MUI applications seem to get dangling locks the first time they are run, even if other MUI applications have been run previously. My current project is one. YAM (the latest nightly build) seems to be another. Both programs use TextEditor.mcc, which makes me suspicious.

Indeed, running the TextEditor demo program, even after running one of the MUI demos, leaves two dangling locks on its home directory. So using TextEditor.mcc (perhaps any disk-based custom class?) the first time after booting seems to generate the dangling locks, too.

This issue has some similarities to ticket 200, and running FlushMUI does clear the locks and allow the drawer to be deleted. But why would MUI need to keep locks on the program's directory, and not any of its contents?

#439 wontfix Implementing non blocking menus Samir Hawamdeh


Actually the opening of any internal menu in MUI will cause the consequent "stop" of any other element running in background (or in the same context)

For example an animated gif in a webpage will be automatically stopped when user will right click into it, or when he will right click into the same area where this active/animated element is present

Another even more important example where this kind of improve can show its necessity could be observed in the Odyssey's video.

When you right click inside the video area in order to open its menu, the video in playing will be "interrupted" and only restarted as soon as the user release the mouse button from it (aka when he definively close the menu)

Improve and solve the current menu's limitation in MUI will be a great step in the right direction and will improve/modernize this important framework even more.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Note: See TracQuery for help on using queries.