What i also notice now, that when that crash from shell on second run happens, and i ignore it (ignore dsi errors), then i have in serial:
newlib.library error: exit() of process 250 called from wrong process 0, using IExec->RemTask(NULL)
@Andy Quote:
So check behaviour when starting with WBRun from shell / starting direct from workbench.
for "wbrun owb" from shell - no crashes (tried 5 times in row run/exit) for dbl-click from WB - no crashes too , also tried 5 times run/exit directly from shell - right on second run crashes
Quote:
If it still doesn't crash from WBrun and WB then examine the differnces between the shell startup and workbench startup code.
Strange why it start to happens only with 1.23, and not with previous ones, will check now maybe there something new changed
At this moment you dind't close it, but just put it under the main owb window by making main owb window active (move it away, and you will see that this dropdown menu still here).
Ok 100% understand now, to solve that i just opened a new ticket in MUI4 asking for a specific enhancement request. Let's see if we can improve this!
Probably your threading backend has an issue with the startup/end message handling. It might only appear now in 1,23 because more threads are involved (garbage collector thread, localstorage thread and, all the mediaplayer threads and so on...).
Quote: At this moment you dind't close it, but just put it under the main owb window by making main owb window active (move it away, and you will see that this dropdown menu still here).
Ok 100% understand now, to solve that i just opened a new ticket in MUI4 asking for a specific enhancement request. Let's see if we can improve this!
The popup doesn't close the moment the url gadget becomes inactive. (As it does in Joergs OWB ) so you can end up withit behind the window if you do click to front (especially if you have ClickToFront set to a single click). Depth gadget will do that to. But as soon as you move the window the popudown list snaps back to it's correct position. This suggests the handler for that menu needs to listen to some more window events that just the movement related ones. Particularly depth changes.
Or Odyssey should be modified to close it if the url gadget becomes inactive (and the menu itself is not active).
What i also notice now, that when that crash from shell on second run happens, and i ignore it (ignore dsi errors), then i have in serial:
newlib.library error: exit() of process 250 called from wrong process 0, using IExec->RemTask(NULL)
Although anything you get after ignoring DSI errors is useless most of the time make sure you don't call exit() anywhere from a child process, it can only be used from the main process.
If there are any threads not started by pthreads but by dos.library make sure you ported the MorphOS code to AmigaOS, for example you have to add NP_Child, TRUE to the IDOS->CreateNewProcTags() tags and wait until all child processes completed before returning from main() or calling exit() in the parent, check the dos.library CreateNewProc() autodoc for example code on how to do that.
The main difference between running it from Workbench or using run in a shell and directly starting it in a shell is that in a shell it's using the shell process, after it quits the shell process is still there. With run/Workbench starting it again creates a new process. In the shell it's using the same shell process again - and if you are using dos.library processes and something is wrong in your code waiting for the childs there may still be child processes running of the old Odyssey when starting the new one ...
and if you are using dos.library processes and something is wrong in your code waiting for the childs there may still be child processes running of the old Odyssey when starting the new one ...
I wondered about that possibility mysefl, using ranger should anable kas1e to chack if all Odysey processes has closed after program quit.
and try to run from shell? without and with manual stack command?
Re: Odyssey 1.23 progress
That's a pointless experiment. Less stack will never make a program work better, nore sdtack can alwatys be added with the stack command. Stack usage can be checked with Ranger.
@tlosm Such test is pointless 100%, more stack never (never-never) cause problems. Only when there is not enough stack.
@samo Thore currently works on calltips class in that bz and 1.16 which you have don't use it. There indeed was some bug , but you ask in BZ not for that. What you ask in BZ its imho outside of mui, its how odyssey done. And, basically, and at least in 1.23, everything logic for me. You just type anythng for have dropdown menus of url-string or of quicksearch, and then, to get rid of it without hitting enter, you press on any area of odyssey (so it deactivates), but then :
1). if you move window, its back so you can see where you now 2). if you start to use another parts of odyssey (pressing buttons, typing urls, whatever) all previous drop down menus auto-closes , what is ok too.
In other words, imho, that BZ is not BZ , but at least Thore accidentally found bug in calltips class because of that which is good, but it not related to what you ask.
Because, you ask "i want windowses autocloses when i press outside of them". And that imho question to Fab, but for me even as it now is fine and good. Even if you don't know that its "deactivated", it make no problems for usage (at least on 1.23).
But to say more about need to note that at least calltips class (i.e. any auto-fill form dropdown menus) just "closes" when you press outside of window on main odyssey window, and not deactivates as url-history or as quick-search. What mean its again related to odyssey's code, not mui.
Edited by kas1e on 2014/2/27 5:30:29 Edited by kas1e on 2014/2/27 5:38:44 Edited by kas1e on 2014/2/27 5:43:03 Edited by kas1e on 2014/2/27 5:50:52 Edited by kas1e on 2014/2/27 6:01:00
make sure you don't call exit() anywhere from a child process, it can only be used from the main process.
Just do search in whole sources on "exit(" and on "exit;" : nothing like exit from process at end.
Quote:
If there are any threads not started by pthreads but by dos.library make sure you ported the MorphOS code to AmigaOS, for example you have to add NP_Child, TRUE to the IDOS->CreateNewProcTags() tags and wait until all child processes completed before returning from main() or calling exit() in the parent, check the dos.library CreateNewProc() autodoc for example code on how to do that.
Sure that what we do even few years ago in first port (without such rewrite nothing can works at all of course, we deal with it at first place when start worry about port).
Sure that what we do even few years ago in first port (without such rewrite nothing can works at all of course, we deal with it at first place when start worry about port).
Search for __amigaos4__ ifdef in those files:
NP_Child, TRUE is there for starting the child processes, but I don't see any code in the #ifdef __amigaos4__/#endif parts which waits in the parent process until the child processes completed. That might have to be done in main() instead anyway.
@joerg JavaScript yep, almost not have specific amiga code, but in Bal / webcore there pretty much of it (not a lot, but still). Instead of adding manually __use_inline__ everywhere i just make assumption from beginning (few years ago when we do first port) that better do everything for newlib , so it all will be the same, and deal later with such kind of bugs. In general there i think for now only 2 or 3 places where newlib usage make difference (clipboard hook usage about which we talk in mails, that websocket's thing and something else don't remember now).
The differences between newlib and the C library used on MorphOS are your smallest problem, and you are confirming what I wrote: You simply compile the MorphOS code and just hope that it works on AmigaOS as well, without even checking it, let alone porting it to AmigaOS. Only if something crashes or doesn’t work at all you check the MorphOS code and port it to AmigaOS, but for porting Odyssey to AmigaOS you have to check all OS functions calls and every single function argument to make sure it’s AmigaOS compatible and if not fix it.
Without using -D__USE_INLINE__ you’d at least be forced to look at the MorphOS/AmigaOS specific parts because of the compiler errors. Not everything is in the #?MorphOS.(cpp|h) files, and not everything is as obvious as missing NP_Child, TRUE in IDOS->CreateNewProc() and waiting for the child processes in the parent, the missing charsets (in the clipboard data, OC_WantedCodeSet, 106 in ILocal->OpenCatalog(), etc.), the MorphOS memory allocator you have to disable or replace (FastMalloc), or at least fix the most serious bugs in it, etc. Not using -D__USE_INLINE__ doesn’t catch everything, for example data only parts like the wrong RawKey codes in the keyboard input, but most of it.
With your current try&error method it will take you several years to port Odyssey 1.23 completely to AmigaOS.
Why are you causing DSI exceptions (handled by the kernel, but all exceptions are very slow) by using SysBase = *((struct ExecBase **) 4); SysBase isn't even used anywhere in the function.
Are you sure the MorphOS NP_StartupMsg is 100% compatible to the AmigaOS NP_NotifyOnDeathMessage? I don't know anything about current MorphOS versions, but StartupMsg sounds like the opposite of DeathMessage ...
With your current try&error method it will take you several years to port Odyssey 1.23 completely to AmigaOS.
With that method we at least have 1.9 and 1.16 (with some bugs, yes, but even in that form it usable and better than nothing). Also by that "method" i port mui mplayer, vpdf (almost, need to fix small bug) and bunch of other small tools from morphos: and they all works. Sure, there can be bugs of course, but at least it not so incompatible between newlib/clib from os to os. Some parts sure, but its faster and easy way to have something for users _today_, not "we works on it, when its done" way. Of course i never-ever want to do all of this, if there left any aos4 devs who motivated enough to do browsers from scratch with modern core (so all that JS and co) to make it all native an fancy-fast looking/working, but as there none, then ppls like me who have only basic skills do it. Your one was really good, fast and stable, but lacking of gui kill it in end. But now its imho too late to make our new gui from scratch after odyssey in develop for years.
And now after fixing that one bug about crash in shell, its all will works pertty fine for end users already and will be much better than previous 1.16. Sure, everything can be done better, but as no one want to do it, then its me (who do not know programming) do it, sadly. And now its even late to make our guis on top of webkit, as Fab do it already with Odyssey. Doing the same again and spend years on it make no sense anymore, better to port it normally with help from everyone who still here :)
Quote:
Why are you causing DSI exceptions (handled by the kernel, but all exceptions are very slow) by using SysBase = *((struct ExecBase **) 4);
I don't have any DSIs there for those ones (and i am on debug kernel with munge). Or you mean they invisibly ?
Quote:
Are you sure the MorphOS NP_StartupMsg is 100% compatible to the AmigaOS NP_NotifyOnDeathMessage? I don't know anything about current MorphOS versions, but StartupMsg sounds like the opposite of DeathMessage ...
Not 100% sure, but when Fab explain us what it do, we understand that is it , and do it like this. At least for 1.9 and 1.16 it was fine enough.
Edited by kas1e on 2014/2/27 9:15:07 Edited by kas1e on 2014/2/27 9:22:49 Edited by kas1e on 2014/2/27 9:25:18 Edited by kas1e on 2014/2/27 9:30:00 Edited by kas1e on 2014/2/27 9:46:29 Edited by kas1e on 2014/2/27 9:48:48 Edited by kas1e on 2014/2/27 9:49:59
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
