This could be all in my head, just making too much of random coincidence, but I have noticed that my application crashes much more when it’s new. First time, its odds are really poor, could crash 1 time out of 4. By the next day, after I’ve run it dozens of times, it’s a real surprise if anything goes wrong.
So I’m forced to wonder if there are system resources kind of deliberately or accidentally tied to a particular application, so when it comes back up after having enountered a problem, it has already sprung that particular trap when it stepped in that hole the first time? Like memory areas that it will tend to re-use or something. Not that it really matters, just curious to see if this turns up a clue I can use.
It’s a medium size project. It uses about the same size memory resources as Deskbar, to give you an idea. It’s a email application, in the Ocaml programming language, running native graphics API etc. That’s where the crashes come from - mainly thread and memory problems I think. Ocaml has runtime garbage collection etc. that needs to be protected against concurrent access. I may have missed something, or it could even be someone else’s error - it sure got better between Ocaml 4.10 and 4.14. I feel bad about it, but then I started running ported web browsers … ha ha.
You write crash, which implies to me that there is more error info available, perhaps even a stack trace. Likewise, if you suspect an OS error, the system log could contain useful information. Without that information, it is difficult to say anything definitive.
I would add that, since you are developing this application, insert debug functions at the most common offending places, to get data about what it is doing when the crashes occur.
Well, sure, but that isn’t really what I was looking for here. If you guys just want to help out with application debugging, I could recommend a couple ported browsers that people are apparently getting from haikudepot and running. They similarly fail somewhat at random.
“Crash” wasn’t a very accurate description, inasmuch as the majority of the failures are stuck waiting on locks. In the past I’ve seen where, in the debugger, which was informative even though it’s going through the ocaml runtime which kind of limits the debugger scope; at the moment my gcc can’t do -g because ‘unrecognized option `–gdwarf-5’'. But the location of the failure isn’t the location of the bug, if there even is one in my code.
To be a little more detailed about the random and unpredictable events - after recompiling the program with minor changes like making a list item a bit larger, I start using it, and the failure rate starts out pretty high - maybe over 50%. After a handful of runs, it’s down to say 10%. I use it dozens of times a day, and the next week it’s pretty reliable.
Without knowing what your application are doing in termos of code, memory and file access, folders, paths, creating/deleting files, etc, it is hard to suggest something. You are the best person to look at it. hence the suggestions for debugging ways.
As a shot in the dark with eyes closed, your app may be accessing files that are only created a bit later, and so crash. The next time the file is already there, and the access succeed and then no crash.
It does! thanks. Plus, it fixes everything else too! Highly recommended. Ha ha. Well, at any rate, the rebuilt application beat the usual odds by a good margin, ran about 8 times before it locked up.