“extern” does not make sense, this is what you use when, you want to tell the compiler that we have variable, but sense its a global, we can't declare it here. But its declared else where.
So drop the "extern", it does not make sense inside TimerFunc()
Hmm... if it´s the SysBase defined by the startup code, the "extern" makes perfect sense here. SysBase is defined "elsewhere", and it should not be a local (automatic) variable of TimerFunc(). That´s what "extern" means here.
But what about this code running outside the main code´s scope?
I think that´s the reason for the "SysBase = *((struct ExecBase **) 4);" thingie. SysBase is declared inside the function (as a local, and here the "extern" indeed doesn´t make any sense. "static" would be the better choice, maybe) and must therefore be initialized with something that makes sense...
But if this is a function running within the main code´s scope only, it´s total nonsense to declare SysBase over and over. Bad coding practice
Sometimes it depends on the source code organization. If the files containing the whole code are organized in static modules, (global) variables like SysBase might not be visible within a certain file if they are not declared "extern".
If you don´t want to mix machine dependend code with "portable" code, it´s best practice not to mess up the "portable" code with machine dependend globals.
Locals must be initialized local, if you don´t declare them "extern" (and define the variable containing the needed value elsewhere). If the "local" variable is declared "extern", this does indeed mean that it´s a global. That´s what SysBase is in most cases. A global. For OS4, it´s a variable defined by the startup code.
Here (in this function TimerFunc() ) it is a question of context, if "extern" makes sense or if the local declaration of SysBase is meant for "clean" code.
If the function is running within the scope of the startup module, "extern" makes perfect sense (and it would lead most certainly to a crash, if you discard the "extern" qualifier). But in this case the initialization is unnecessary. SysBase is initialized already (by the startup module).
If it´s running outside this scope, the correct value of SysBase should be provided by parameter and could be used directly then.
Back in 68k times it was quite usual to initialize a local SysBase by "SysBase = *((struct ExecBase **) 4); " (although most today´s compiler´s startup code provides for SysBase), but with the advent of zeropage protection, this is bad practice.
For me, this function´s code looks a bit messy. On the one hand, global SysBase is used (MOS and OS4 port), on the other hand, "bootstrap" initialization of SysBase is used (obviously, meant for 68k systems). The scope is quite unclear here...
Edit: If the code compiles without the "extern" AND without the initialization, there must be a global SysBase already somewhere within the source file. But then it should throw at least a warning about redefinition... weird.
When i exit, all of them exit too. All seems fine.
Then i run second instance from shell : dsi, ignoring of which run those processes again fine and browser works. Just after i ignore DSI i have on serial:
Quote:
Task 0x65E793E0 (Shell Process) bad access @ 0x63B94608, pc = 0x018200A8, lr = 0x0182012C,
Also do check this way: i just run odyssey from shell, exit, close that shell window, spawn new one, run odyssey : all works (but that expected, as it kind of new instance).
Running second time in new tab : works too. Running third time in another tab: works too.
"endcli" in all tabs after i run second or third instance works fine, i can exit from them, etc (so no locked or whatever).
Only problem is exactly in the same shell window run/exit/run again.
Quote:
Have you tried running this from gdb? I know it has it's limitations but it might still catch something...
Well , as it will be inside of gdb, it will spawn for every new run new process and there will be no crash :) (as it didn't crashes for as in all places, only direct run from the same shell window in the same tab). Or you mean attach to gdb when its already crashed ? Tried as well, backtrace / bt just show some mess. Or if you mean to do so because dind't see crashlog : nope, our reaper catch it fine, i even post it before and recopy it in that post again.
Edit: If the code compiles without the "extern" AND without the initialization, there must be a global SysBase already somewhere within the source file. But then it should throw at least a warning about redefinition... weird.
It'll quite happily compile without error that way under OS4 as the SysBase variable is not access directly ( functuion calls are using IExec) (if -wall is in use it might throw up an warning about it being unused)
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...).
But it just happens when i only run odyssey , do nothing (so only about: page), quit, and run it again. At thise moment imho only few threads involved (those which was in 1.16 as well) ?
How come your trace has no line numbers? Are you not building with -gstabs? Unless that (linenumber in trace) doesn't work for c++ code?
Enabling -gstabs lead to 1gb binary or something, 700 or 800mb do not remember => unpossible to works with, as all very uber slow and co (compiling, linking, etc)
Quote:
f you run a different program afer odyssey do you get a crash? Perhaps try one that uses pthreads. (OWB or blender or something).
Yep, have crash if i just run odyssey, then close, and then run joerg's owb for example. Crashlog:
Dump of context at 0xEFD8EBA0
Trap type: DSI exception
Machine State (raw): 0x0200F030
Machine State (verbose): [ExtInt on] [User] [FPU on] [IAT on] [DAT on]
Instruction pointer: 0x7EC3A9C0
Crashed process: owb (0x65F737E0)
DSI verbose error description: Access not found in hash or BAT (page fault)
Access was a load operation
0: 00004000 63689310 63F552D0 021D69A6 00004000 00000000 00000000 0181CC00
8: FFFFFFFF 00000000 00000001 80000017 63689320 63F6FC58 00000000 6526A6C0
16: 7EC45B44 00000001 68293420 63647400 00004000 00000000 00000000 00000001
24: 6FF90000 00000001 020A0000 00000000 00004000 020A0000 020C2BEC 021D69A6
CR: 55953E59 XER: C000BE6F CTR: 00000000 LR: 0181CC00
DSISR: 40000000 DAR: 00000000
Enabling -gstabs lead to 1gb binary or something, 700 or 800mb do not remember => unpossible to works with, as all very uber slow and co (compiling, linking, etc)
Well enable it just for the areas that crash then! How do you expect to debug something without debuging enabled? It might be slow but you'll find the bugs in less iterations. Disable optimisation too, to get a more complete stack trace.
As other programs are crashing it suggest the shell process is being trashed in some way. Very hard to see how.
Writing, reading and using ID_CSET is still missing.
Quote:
Quote:
Are you sure the MorphOS NP_StartupMsg is 100% compatible to the AmigaOS NP_NotifyOnDeathMessage?
Not 100% sure,
You don't know what it does on MorphOS and use a random AmigaOS tag as replacement and even think that could work Are you joking!? If you don't understand the MorphOS code at all and can't port it to AmigaOS why don't you simply use the working AmigaOS code from OWB instead?
As for destroying the shell/process structure: Search for all FindTask() calls in the MorphOS code, delete everything it does with struct Task, struct Process, etc., and reimplement the code for AmigaOS. If it's not the child processes it's some other incompatible MorphOS code you didn't port to AmigaOS yet, most likely something messing around with struct Process.
So you have this function initializeThreading() that does some thing bad, it ends up in the kernel some where.
Clearly you should investigate where in initializeThreading() that things go wrong.
My wild guess is that it might have some thing to whit “New” Mutex initializers.
Just do printf() for etch line, or if your good whit GDB set backpoint at initializeThreading(), that way step line for line, just remember to compile whit -ggdb to get more debug information.
I don't think this code I'm quoting is has anything to do whit the crash, but for me it looks like some thing thats going to lockup.
How can you disable multitasking and expect some one to signal the program, when this is the only program running.
As written in the CAUTION part of the autodoc calling IExec->Wait() breaks the forbid state and multitasking is enabled, after IExec->Wait() returned it's disabled again.
You don't know what it does on MorphOS and use a random AmigaOS tag as replacement and even think that could work
We replace it on equivalent after fab explain what it do on morphos. But on amiga you can't be sure on 100% with anything, that why i say "not on 100%". If you have any other better solution then why not of course , will try it too :)
Quote:
why don't you simply use the working AmigaOS code from OWB instead?
Its not that easy, as everything refers to each other , i was happy enough when i just can reuse your pointers code.
Quote:
As for destroying the shell/process structure: Search for all FindTask() calls in the MorphOS code, delete everything it does with struct Task, struct Process, etc., and reimplement the code for AmigaOS. If it's not the child processes it's some other incompatible MorphOS code you didn't port to AmigaOS yet, most likely something messing around with struct Process.
Do search for all FindTaks in all the code everywhere, and there is all files which contain it (not many):
Through i am about to die on it for today, and can't think anymore about :) Maybe you will find something if you have some time . Probably Mediplayer parts can be done somehow bad (as it fresh stuff in 1.23)
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
Are you joking!?
