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?
The crashes seem random from those logs you posted.
But something is getting trashed.
I would suggest you go through all amiga specific structure allocations and check they are all the right size, there's an outside chance of an allocation of a pointer to struct rather than a struct or something like that. (ie sizeof(struct foo*) instead of sizeof(struct foo) very easy mistake to make and hard to spot ... and you rarely get a DSI from such errors.
I would suggest you go through all amiga specific structure allocations and check they are all the right size, there's an outside chance of an allocation of a pointer to struct rather than a struct or something like that. (ie sizeof(struct foo*) instead of sizeof(struct foo) very easy mistake to make and hard to spot ... and you rarely get a DSI from such errors.
If it would be something like that he'd get random crashes no matter how he starts Odyssey, but not never crashes for the 1st run and always for the 2nd in the same shell.
Some cleanup seems to be missing somewhere which results in destroying something, or even more likely setting it to some data of Odyssey which is freed after exit, in struct Process or something else the shell is using.
@kas1e Use tools like Ranger or Scout to check the struct Process of the shell you are using for starting Odyssey, nothing must change after the 1st run but something probably does. Knowing what is trashed would help a lot.
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).
Same crash (i.e. run owb, then exit, then owb_copy), same crash, same stack trace.
@joerg Quote:
Why are you using static Mutex* atomicallyInitializedStaticMutex=NULL; What was the reason you did that?
We add it with Deniil few years ago, and all what i found now in the logs is just some irc quote:
Quote:
[23:49] <Deniil> this line: [23:49] <Deniil> static Mutex* atomicallyInitializedStaticMutex; [23:49] <Deniil> should be static Mutex* atomicallyInitializedStaticMutex=NULL; I think [23:49] <Deniil> because in initializeThreading() there is if (!atomicallyInitializedStaticMutex)
So we imho add it just in case, and now i remove it back, and do check : all works as before: i.e. crash on second time as well.
@joerg Quote:
Use tools like Ranger or Scout to check the struct Process of the shell you are using for starting Odyssey, nothing must change after the 1st run but something probably does. Knowing what is trashed would help a lot.
No idea what it is, but "MUI imagespace screen notify" child process is still running after exit, and it's still waiting for some signals which shouldn't happen either.
Using something like Scout instead of Ranger would be better, it includes much more things from struct Process like the Input(), Output() and ErrorOutut() files (pr_CIS, pr_COS and pr_CES), current directory lock, etc.
No idea what it is, but "MUI imagespace screen notify" child process is still running after exit, and it's still waiting for some signals which shouldn't happen either.
Dunno what is exactly, but that thing leaves from any mui app after exit (if i even run for example wookiechat, or amirc, or anything). So imho should be not relaed.
Quote:
Using something like Scout instead of Ranger would be better
Tried one from os4depot, and once run and press on Tasks it just crashes.
@Andy Same crash with your scout too , but its probably because i am on debug kernel + munge , and DAR are: CCCCCCD0 (so its munge then). Ignore dsi help through. Will try now.
Btw, as i see from screenshots, tc_UserData didn't clean after exit. I.e. in pure shell its 0x000000, then it some value when odyssey runs, and then its still the same value when odyssey quit.