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)
Way too much nonsense for even trying to fix it (using malloc() instead of exec memory allocation functions with MEMF_SHARED to allocate structures which are passed to OS functions like IDOS->StartNotify(), trying to mess around with parts of the undocumented tc_ETask which don't exist, trying to send Arexx messages to an "AMBIENT" port, etc.).
If it's something in these parts and not NP_StartMsg != NP_NotifyOnDeathMessage it might be using tc_UserData for 2 different things: In BCThreadSpecificWTF.cpp for a pointer to a MinList and, only on AmigaOS but not on MorphOS, in BCThreadingMorphOS.cpp and BCThreadingWTF.cpp for a NewThreadContext pointer.
Maybe you will find something if you have some time
these may or may not be critical but I see the following:
In main.cpp you roll your own struct NoifyRequest. That should be allocated with AllocDosObject() since version 51.
In splashwindclass.cpp you set pr_WindowPtr explicitly, you should use IDOS->SetProcWindow() since version 50.
Same again in downloadlistclass.cpp
Otherwise I couldn't see any bad other process access etc. The code uses tc_UserData a lot and never seems to save the original value (which is fine for tasks you spawn) if that happened to the main process it might cause bad affect, but I didn't see anywhere where that happened
these may or may not be critical but I see the following:
In main.cpp you roll your own struct NoifyRequest. That should be allocated with AllocDosObject() since version 51.
This one is, even if not for his current crashes (unless he has too few RAM). You must not pass MEMF_PRIVATE memory to OS functions and the C library functions like malloc() of course use unlocked MEMF_PRIVATE memory.
A quick request, I know, it's too early for requests...
In MIME Types can the behaviour of %f be changed, at the moment it ignores anything else in the gadget. Can the be changed to embed the temp filename into the gadget contents.
For example %f.m3u would create a file called OWB_TempFile_1393543241.m3u
which would enable amigaamp3 to work with a simple external viewer call of "appdir:amigaamp3 %f.m3u" instead of the dos script I have to use now to use wget to download the m3u file and run amigaamp3.
Amiga user since 1985 AOS4, A-EON, IBrowse & Alinea Betatester
All that dos_notify stuff in no use and commented out (see at end of the main.cpp commented dosnotify_init(); and dosnotify_cleanup(); as well as dosnotify_start() in use only in bookmarkgroupclass.cpp, where it also commented out.
I just dind't remove it from code, as it change nothing as functions didn't called at all anywhere.
@Joerg Quote:
trying to mess around with parts of the undocumented tc_ETask which don't exist
MachineStackMarker.cpp wasn't touched at all and its something which appears to be since 1.16 and need fixes, yes. Maybe you can help with ?
Through, while it can be related to some crashes in JS, 1.16 (with that untouched file) , didn't crashes on second run from shell like it do with 1.23 now.
Quote:
trying to send Arexx messages to an "AMBIENT" port
That to be fixed too: for download manager now def_icons will be shown (i.e. if you download .lha file, you will have image of .lha file) : on mos its done for ambient, for us it need to be replaced for deficons or whatever. That to be done, but currently cause no harm, and we just have simple plain image for all downloaded files currently. But that to be fixed of course, just after that sucking process trashing.
@joerg Quote:
it might be using tc_UserData for 2 different things: In BCThreadSpecificWTF.cpp for a pointer to a MinList and, only on AmigaOS but not on MorphOS, in BCThreadingMorphOS.cpp and BCThreadingWTF.cpp for a NewThreadContext pointer.
Have any better idea ?:) Anyway, as Fab says "Probably your threading backend has an issue with the startup/end message handling.", then it still can be that NP_StartupMsg/NP_NotifyDeathMessage, but we found nothing better but to do it like this. If you have other ideas, will be nice to try them out as well.
In morphos SDK i found:
from exec.doc: Quote:
TASKINFOTYPE_STARTUPMSG
returns pointer to struct Message passed in with NP_StartupMsg or ASKTAG_STARTUPMSG, NULL if no startup message was specified, at the DataPtr address if the DataSize is large enough. This message is ReplyMsg()'d by the system when task/process exit. Size = sizeof(struct Message*)
a: a message that is replied at end of task a: it's used for thread synchronization, in this case (waiting for thread end) a: message is used to wait for end of child the goal is to implement webkit thread api
q: end, not startup?
a: and join() waits for child a: BCThreadingMorphOS.cpp -> waitForThreadCompletion()
q: so then we could use NP_NotifyOnDeathMessage on OS4
a: you use anything you want, as long as you can make it behave the same
-----
q: what is TASKINFOTYPE_STARTUPMSG btw ? a: a tag to retrieve the startup message passed at task/process creation q: mos specific ? a: yes
@Andy Quote:
In splashwindclass.cpp and downloadlistclass.cpp
Splashwindow used for splashwindow when fontconfig generation progress window starts , and when cache file is done, it didn't starts , so can't be our problems with trashing of process. Same for donwloadlistclass: its only in use when we do downloading, so also can't be. As for reproduce crash i enough just run and exit and run again.
@Severin If it something which happens on morphos also, then its better to send req for Fab
Edited by kas1e on 2014/2/28 5:37:21 Edited by kas1e on 2014/2/28 5:42:29 Edited by kas1e on 2014/2/28 5:48:28 Edited by kas1e on 2014/2/28 5:55:58
it might be using tc_UserData for 2 different things: In BCThreadSpecificWTF.cpp for a pointer to a MinList and, only on AmigaOS but not on MorphOS, in BCThreadingMorphOS.cpp and BCThreadingWTF.cpp for a NewThreadContext pointer.
it still can be that NP_StartupMsg/NP_NotifyDeathMessage, but we found nothing better but to do it like this. If you have other ideas, will be nice to try them out as well.
It seems it can be used, the MorphOS name just makes no sense, according to what you quoted it's more like a NP_EndMsg. But not that way on AmigaOS, check the dos.library autodoc: The argument of NP_NotifyOnDeathMessage has to be a struct DeathMessage! You have to use #ifdef __amigaos__ struct ThreadStartMsg { struct DeathMessage tsm_Msg; void* tsm_Result; }; #else struct ThreadStartMsg { struct Message tsm_Msg; void* tsm_Result; }; #endif and fix all code using ThreadStartMsg, don't use malloc() but IExec->AllocVecTags(sizeof(struct ThreadStartMsg), AVT_Type, MEMF_SHARED, TAG_DONE) to allocate it, IExec->FreeVec() to free it, etc.
Edited by joerg on 2014/2/28 8:29:06 Edited by joerg on 2014/2/28 8:32:31
struct DeathMessage has no member named mn_Node, nm_ReplyPort and mn_Lenght.
checked structs of deathmessage and message and they sure different. Commented those parts out will not help as well, as in the waitForThreadCompletion() it's all in use
Edited by kas1e on 2014/2/28 9:07:24 Edited by kas1e on 2014/2/28 9:13:06
@kas1e Maybe I'm wrong, but OS4.1 SDK headers are: <pre>... struct DeathMessage { struct Message dm_Msg; /* Embedded exec message structure. */ int32 dm_ReturnCode; /* Primary process return code, set by DOS */ int32 dm_Result2; /* The value returned from IoErr(),set by DOS */ }; ...</pre> And as it has/points to struct Message: <pre>/****** Message *****************************************************/
struct Message { struct Node mn_Node; struct MsgPort * mn_ReplyPort; /* message reply port */ uint16 mn_Length; /* total message length, in bytes, (include the size of the Message structure in the length) */ };
/****************************************************************************/</pre> It could be something like: startup_msg->tsm_Msg.<b>dm_Msg.</b>nm_Node.ln_Type = NT_MESSAGE;
Maybe not directly related to the crash, but in the crashlog you have 0xABADCAFE in register r2. That's the value used for filling memory allocated with IExec->Alloc[Mem|Vec|VecTags](), something is accessing allocated memory which wasn't initialized yet. IIRC r2 is used on MorphOS for something MorphOS specific which doesn't exist on AmigaOS, make sure r2 isn't accessed anywhere in the MorphOS code you are using.
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
Are you joking!?
