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.
Btw. there's at least one call to MOSSYS: in the printing routines, opening printer prefs I assume.
That why i don't want to give any beta to anyone because i know there will be report of such kind : it fixed in 1.16, but in times when you ask for beta for show it wasn't in 1.23 (trivial change, but beta is beta). Do all tests on 1.16 plz.
@Joerg Quote:
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.
What is strange is that its different all the time (i mean values in registers). Now it show abadcafe, another time its all random, another time even meet with deadbeef. Sometimes DAR are 0x0000000 , some times some "fine" value.
I think i need to put debug prinfs in the void initializeThreading() after each call, just because it crashes on second run after initializeThreading() prinfs, but didn't print "establishIdentifierForThreadHandle() adding thread id 1", so something between. Maybe from that somehow can understand wtf happens.
The problem may be that for whatever reason there is some context information (from things like threading lib, clib) connected to the Shell task that (partly) "survives" the "exit/restart program" process and gets re-used when you start the program the second time but shouldn't be re-used.
If it is known (unlikely?) where such context information is stored exactly you could try to NULL it out very early during program start as a test.
Yep, have crash if i just run odyssey, then close, and then run joerg's owb for example. Crashlog:
I don't understand why you don't debug your own executables, but this crash in OWB 3.32 is an intentional crash (accessing 0 in an internal exception handler used for example for debugging deadlocks) and therefore useless to find your bugs in Odyssey. Except that Odyssey returns with the SIGBREAKF_CTRL_E signal set, which it shouldn't do.
@all Just enable more debug, and so, when i first run it :
initializeThreading()
we in initializeThreading(): inside of the !atomicallyinitializedstaticmutex and before StringImp::empty
we in initializeThreading(): before atoicallyinitializedstaticmutex = new Mutex
we in initializeThreading(): before threadmapmutex()
we in initializeThreading(): before syncportmapmutex()
we in initializeThreading(): before threadReplyStateMapMutex()
we in initializeThreading(): before wtfThreadData()
we in initializeThreading(): before initializeRandomNumberGenerator()
we in initializeThreading(): before s_dtoap5mutex = new mutex
we in initializeThreading(): before initializeDates
we in initializeThreading(): before mainthreadidentifier = currentThread()
establishIdentifierForThreadHandle() adding thread id 1
mainThreadIdentifier 1
isMainThread() 1
ThreadCondition::ThreadCondition()
ThreadCondition::ThreadCondition() OK
createThreadInternal([OWB] IconDatabase)
..blblabla...
After that i exit, threads cleans, etc, and do run second time , and have:
initializeThreading()
we in initializeThreading(): inside of the !atomicallyinitializedstaticmutex and before StringImp::empty
we in initializeThreading(): before atoicallyinitializedstaticmutex = new Mutex
we in initializeThreading(): before threadmapmutex()
we in initializeThreading(): before syncportmapmutex()
we in initializeThreading(): before threadReplyStateMapMutex()
we in initializeThreading(): before wtfThreadData()
Dump of context at 0xEFD8DBA0
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 (0x65EC19F0)
DSI verbose error description: Access not found in hash or BAT (page fault)
Access was a load operation
0: 65349FC4 65548940 DEADBEEF 65349FC0 65978600 65978600 63EA9040 65978610
8: 000000E3 020C2BEC 651A43F0 021D69A6 00000154 65777BA8 00000000 69149040
16: 7D4E70B4 00000000 66D05420 65548C08 02290000 02290000 00000000 00000001
24: 659F5DD0 659F5DD0 00000000 020A0000 7ECB43B0 65978600 65349FC0 020C2BEC
CR: 35953E95 XER: E000BE6F CTR: 018200B0 LR: 0182012C
DSISR: 40000000 DAR: 65349FC8
It could be anything, something in struct Process overwritten, or in struct CommandLineInterface, dos.library Input()/Output() files replaced by Odyssey but not restored on exit, ... As long as Roman doesn't build his executables with debugging information (-gstabs) and checks where exactly it crashes and what it's doing there on the 2nd run it's impossible to find out what it is.
If USE(WEB_THREAD) is enabled you are mixing MorphOS threading with pthreads threading: if (pthread_main_np() ...). And the wtfThreadData() function isn't there, it's probably in the include file.
Also enabled -gstabs for BCThreadingMorphOS object, and crash on second run happens later than before by prinfs, i.e.:
Quote:
initializeThreading() we in initializeThreading(): inside of the !atomicallyinitializedstaticmutex and before StringImp::empty we in initializeThreading(): before atoicallyinitializedstaticmutex = new Mutex we in initializeThreading(): before threadmapmutex() we in initializeThreading(): before syncportmapmutex() we in initializeThreading(): before threadReplyStateMapMutex() we in initializeThreading(): before wtfThreadData() we in initializeThreading(): before initializeRandomNumberGenerator() we in initializeThreading(): before s_dtoap5mutex = new mutex we in initializeThreading(): before initializeDates we in initializeThreading(): before mainthreadidentifier = currentThread()
<<CRASH>>
stack trace on second run when that crash happens with -gstabs on that object looks like this:
It sounds stupid, but what happens if you make a copy of the exe and the first time you start the original (owb). And the second time you start the copy (owb_copy).
initializeThreading() seems to call a lot of functions just to initialize static data in these functions, which shouldn't be required, at least in the ones included in the sources there is nothing which can only be done from the main thread. But if there is a bug somewhere which requires doing that for some strange reason you probably have to do it for everything, for example add threadMap(); syncPortMap(); threadReplyStateMap(); in initializeThreading() as well.
Why are you using #ifdef __amigaos4__ static Mutex* atomicallyInitializedStaticMutex=NULL; #else static Mutex* atomicallyInitializedStaticMutex; #endif ? That makes no sense either, but since you added it there must have been something seriously wrong somewhere which required doing it, for example a buffer overflow writing to some .bss data and adding =NULL moved it to the .data section and now something else in .bss is trashed instead. What was the reason you did that?