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.
@georg So, because of that the same value of tc_UserData, i still Null exactly that tc_UserData and crash gone !!
Through i do not know where that tc_UserData is used as well, as in BTThreadingWTF.cpp i change that as i show before, but still NULLed it at begining deal with crash , maybe somewhere else it in use, dunno.
On exit, tc_UserData still have that value from odyssey, but with FindTask(NULL)->tc_UserData = NULL; at main there no crash anymore.
I even do run it 10 times in row, and valut in tc_UserData always the same (i was expected it will be changed from run to run, after we NULL it)
On exit, tc_UserData still have that value from odyssey, but with FindTask(NULL)->tc_UserData = NULL; at main there no crash anymore.
Instead of setting it to NULL at the start of main() you should do it at the end. It's the same for Odyssey, but other software might have the same problem if you don't set it to NULL. Or even better at the start and at the end, in case someone runs another program in a shell which doesn't clear it on exit before Odyssey.
And of course you should fix the actual bug in Odyssey as well.
So, OS4 is incompatible with AmigaOS 3.x? Many programs use tc_UserData. tc_UserData is meant to be *used* by the programs, not by the operating system (hence the name).
And of course you should fix the actual bug in Odyssey as well.
If only i found where is it :)
@georg Only now got what you mean, you mean exactly BCThreadSpecificWTF.cpp (i just forgot about that one at all), and there i didn't change anything, its still the same tc_UserData everywhere (in threadSpecificKeyCreate() and in threadSpecificKeyDelete() ).
So, OS4 is incompatible with AmigaOS 3.x? Many programs use tc_UserData. tc_UserData is meant to be *used* by the programs, not by the operating system (hence the name).
It's not a bug in AmigaOS but in Odyssey (maybe in Roman's parts only), it obviously crashes if tc_UserData wasn't NULL when it's started.
tc_UserData is indeed for user use, but you can't assume any value before you use it if you running on someone else's process (shells in this case but could be another program running Odyssey direct) or after you run some external program on your process (not relevant here).
To be most "friendly" you might save and restore the start value if running in someone else's process, but then again they shouldn't assume you did that.
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.
That is a process created by MUI which will flush all unused images used on a just closed screen. This process is started with NP_Child=FALSE.
and NEWLIST(...) is bullshit, not needed, when using AllocSysObject(...).
so *key should be a (struct *Node) type, there for malloc() is wrong command to allocate the memory, because malloc() was private memory, and t->tc_UserData comes from outside the process.
I have a problem to understand way the List is allocated here at all, should this not be provided when thread starts, after the thread is closed the (struct *Task) will be deleted so getting or poking at Task -> tc_UserData after the thread has stopped, is like asking for trouble, hopefully this not what is happening.
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
