after Owb working i think one another great stuff will be have DnsCrypt on AmigaOs :) this two software together will be a great couple .
Plus today i found on aw an interesting post about youtube video is better i think you check this script on Owb 1.23 for more compatible youtube video play
after Owb working i think one another great stuff will be have DnsCrypt on AmigaOs :) this two software together will be a great couple .
Not me, i have enough in pipeline :)
Quote:
Plus today i found on aw an interesting post about youtube video is better i think you check this script on Owb 1.23 for more compatible youtube video play
While, our threading related changes are the same 1:1 as we do in 1.9 and in 1.16 (which didn't have such problem)
Stack_cookie of course set as before as well.
What is strange, why it didn't crashes at all from amidock (does not matter how many times i run/quit it), but when i do it from shell, then right on second run it crashes.
did mean stack ok (stack cookie is piece of code which you include to the program, which automatically set your stack on the value you need, without needs to enter it manually in shell). I.e. code have now:
@jabirulo "Run owb" from shell works fine too (tried 5 times to run/exit). Only when i just run it directly from shell as it: first run ok, then close, then second run crash. 100% reproducable.
"Run owb" from shell, "execute" from wb, run from amidock : all ok , can do it 10 times in row for test without problems, but just direct run from shell crashes on second run. All registers have all kind of different values (nothing like nulls, or feedface/abadcade/deadbeef), just a 80000003 dsi crash.
ignore DSIs skip error fine and load odyssey, so it should be something trivial or at least not _that_ hardcore.
Whole crashlog:
Dump of context at 0xEFC10BA0
Trap type: DSI exception
Machine State (raw): 0x0200F030
Machine State (verbose): [ExtInt on] [User] [FPU on] [IAT on] [DAT on]
Instruction pointer: in module kernel+0x0002009C (0x0182009C)
Crashed process: owb (0x6335EA50)
DSI verbose error description: Access not found in hash or BAT (page fault)
Access was a load operation
0: 65ABF604 64475950 020C2BEC 65ABF600 60534B60 60534B60 00000108 60534B70
8: 000000D3 020C2BEC 00000100 021D69A6 FFFFFFF7 64915BE0 00000000 65FF26C0
16: 7D4C9040 00000000 63368090 64475C08 02290000 02290000 00000000 00000001
24: 62ADF7D0 62ADF7D0 00000000 020A0000 7EC96FBC 60534B60 65ABF600 020C2BEC
CR: 22842B84 XER: 60008F50 CTR: 018200B0 LR: 0182012C
DSISR: 40000000 DAR: 65ABF608
Typically crashes in sub process/tasks/threads when program quits are because the processes did not quit before the main program.
I don't know what code looks like, but its some thing you should investigate whit DebugPrintF or some thing.
Beside that I'm also thinking about the difference between starting a program from shell and wb, is that in one case you read wbstartup message, and the other you read the shell arguments.
Maybe some different in the initialization code, that comes back to haunt you at the end of the program.
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.
News feed
OS4 Feedback forum
OS4Depot Feedback 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
