Finally I found the reason for the strange crashes on Amiga and MorphOS on destroy of LCL apps. And now I also understand why it was so difficult to find it. It was … drum roll … not in my code :-O. It’s in the library units of MorphOS and Amiga. Little bit about the basics. On AROS I open the Library (belongs to a unit) inside the initialization section and close it again in the finalization section. I’m used to this behavior from windows DLLs. At Amiga and MorphOS a different way is used. The OpenLibrary is done in the initialization section (for Amiga) or must be done manually (MorphOS). On this OpenLibrary call the ExitProc of the unit is connected to a CloseLibrary routine. So far sounds good, but it seems the problem is that the ExitProc is called BEFORE the finalization of the unit, long time before as it seems, hence the muimaster.library is already closed when I try to destroy my MUI Objects which horrible crashed.
I placed some Debug output in the InitMuiMasterLibrary and CloseMuiMasterLibrary and can clearly see that the CloseMuiMasterLibrary happen before my LCL destroy things are called. I will play around a little bit with it. But in the end I have to talk with Charlie (Maintainer of FPC-MorphOS) about this, how to solve this problem.
This explain also other crashes I experienced before (like the crash of CloseFont for example)
The flickering is much better, the picture was painted too often and the message loop was polled too seldom. Optimized this a little bit, now it happens very seldom. When I started this tests first I implemented a simple Speedtest which does the same calculation for one second and then count the successfully calculated pixels.
So of course would be nice to have it also in this graphical server and optimize the number of pixels requested from each client. I noticed the Amiga 1200 with 68060 50Mhz only finished 3-4 Pixels per second, I know it is slow, but that slow. (Besides this I’m surprised how fast the MacMini with MorphOS is, nice :-)) But then I remembered that the m68k freepascal does not use the FPU. By default it uses softfloat routines, which of course are very slow. But my automatic compiler server also compiles the FPU version of all units (enable at compiler with -Cf68881 and use FPU compiled units). The fpu compiled version is much, much faster now 200 px/s. Wow now the amiga really add some pixels to finished image. (Before also some, but less than a line ;-))
Speed test of the „Amiga Cluster“
It should be noted that the 192.168.0.122 (and 127.0.0.1) is a Computer with eight cores but only one is used here (in fact, two because 127.0.0.1 is AROS hosted on the same computer), I didn’t implement multicore threading.
I played again a little bit with networking things, especially on different platforms. Very nice that the most sources now compile out of the box at Linux, AROS, Amiga and MorphOS only very little ifdefs inside, and even they could be omitted by extending the Amiga-like-RTLs with some unix functions.
I wrote a little Lyapunov calculation program which sends the pixels to calculate via network to other computers to let them calculate. Lyapunov is very good for such things because it has very little inputs and results but rather long calculation time per point.
I compiled and run the client for all platforms I have available currently:
- i386-AROS (Linux Hosted – AMD FX 8120)
- powerpc-MorphOS (Mac Mini)
- m68k-amiga (Amiga1200 68060/50)
- x86_64-linux (AMD FX 8120)
- i386-linux (Intel Atom 230)
- arm-linux (Raspberry pie 1)
All compiled from the same source.
The Server and Image Viewing is done at AROS.
The power of Freepascal/Lazarus at its very best.
The white pixels are already send to some client but the result is not arrived.
The image is flickering a little bit (therefore in the movie sometimes no image to see) because I didn’t care much about the image plotting. I’m not sure why the image is flickering maybe the network communication take too much time so not enough time to draw the image.
Playing around with the LCL for MorphOS, seems to work nicely, but (as described last time already) it crashes on Exit. I tried to find the reason for it. It seems that that the MUI Objects are kind of destroyed already, even still visible on the screen. Due to the special way to work in LCL I do not like the automatic destroy function of MUI. If you build up a mui application with application, window, items in there you usually only need to destroy the application and every thing else will just be automatically destroyed. Of course thats not what we want to use for LCL (or it would be impossible to destroy single button/Windows and so on). Long time before at AROS I played around with it and the best solution is to just unlink the item from its parent and destroy it by hand (MUI_DisposeObject) because then it is always in my full control when an object gets destroyed or alive.
Seems thats exactly my problem now. When I begin to destroy my objects at some point it seems that the MUI Objects are already destroyed, so it crashes, but this object (window) is still visible on the screen. I removed all MUI_DisposeObject from my code and still the Window gets destroyed somehow :-O and the mui objects are invalid. Here happens something I do not understand. Really strange thing, maybe its some special „new MUI Version“-thing? I don’t know and not really an idea how to continue here. Maybe I need to write a simple non-LCL program where I do the same and try to find out this strange behaviour.
As written yesterday the it seemed that the Hooks just do not work. This was right because I deactivated them. After reactivation the Button clicks and close windows works very nicely. But the Layout Hook still does not work. The routine for setting the min/max and layout is called. I added some debugoutput and noticed that the size of the window seemed to be negative. No wonder it won’t open it. But why its negative it should not be, the LCL window gets a valid size. In the end my very first idea was right… the structure is wrong which is used to get the Min/Max/Def sizes.. all Values there are set as ShortInt so -127…128 wich is rather unusual for Width/height of windows and really when look into AROS units this are Words so 0..65535 so no wonder MUI refuses to open the windows it just didn’t get the real size.
S I fixed the structure (locally) and voila its working. So I compiled some of my test programs from the fpc-tests repositiory to see where we are… because some are animated I made a little video out of it:
Link to the video
What we see:
Upper Line from the left:
- Button/Memo: To Test click events, and Enabled/Disable of Button, completly works
- Menu: Does not work at all, because at the moment it crash if I activate it again, maybe it cant stand emty menustrips, which would be bad because Menustrip only can be added on creation not later added.
- Progressbar/Busy bar: Works
- Timer: Works
Lower Line from the left
- ComboBox: a little bit strange, the upper comboBox is there, even react on clicks but is not drawn.
- Edits: the normal edits work as expected… just my SpinEdits (2 Button + Edit) are not shown at all
- Scrollbars: again they are there but not visible.
from this things I slowly get an idea what happen and this would be REALLY bad! All combined items does not work! Maybe because I added an LayoutHook??? But this would mean you can never put a combined Element like the Scrollbar into a Group wich has an own Layouthook. I would call this a bug.
In the Video is also easy to see that the size calculations are not right… especially at the Button test, the Memo is alBottom, but draws alreay over the windowborders. I took me very long to make this right on AROS… seems at MorphOS its again different.
Besides this all programs crash on exit at the moment. I try to debug it but its really hard because you have to dissassemble the program then use the offsets from the crash log to find the position where it gave the problem. It seems that the problem appears that the LCL access some property short BEFORE the item gets destroyed but this crash already. The item is not destroyed because its still visible on the screen. No idea whats wrong there maybe with debugtexts will be better.
Charlie did an awesome job to add some more festures to the MorphOS (and Amiga) Freepascal compiler so FINALLY i was able to compile the LCL for MorphOS. I had to deactivate a lot of stuff for now, but all not very important. Some are expected to be a problem like the cybergraphics things… other more surprising for me like diskfont library which does not exists (the freepascal wrapper unit for it only, I guess)
But also other stuff I have to think about, especially, GetAttr, SetAttr, CallHook, maybe I make some wrapper functions to make it easier to handle them at all three platforms. It kept crashing all the time… of course bcause I forget AGAIN that you need to to Open the libraries for the needed units, there is the most interesting point, when to init because some initializations will need it. Finally I found the best position for now.
So it does not crash anymore but also does not open a window… seems my Hooks for MorphOS does not work well because the Layouthook is never called, and the Window open attribute does nothing. After deactivating the LayoutHook it at least start it does not care about the size, thats the reason the Button is full window size. I have the Hooks working in an separate MUI testprogram so I guess I just did something wrong in the LCL. So because the Hooks does not work even the close button does nothing in MorphOS.
So much work, so little time.
