Program received signal SIGSEGV, Segmentation fault.
0x04b4eb37 in ?? ()
(gdb) bt
#0 0x04b4eb37 in ?? ()
#1 0x00000038 in ?? ()
#2 0x042c0000 in ?? ()
#3 0x00000028 in ?? ()
#4 0x000001f8 in ?? ()
#5 0x69e01e7b in nvoglnt!DrvValidateVersion ()
from C:\WINDOWS\system32\nvoglnt.dll
#6 0x00000000 in ?? ()
(gdb)
I've seen in Process Monitor a few odd things about these CTD's that Oolite is having.
In one of the crashes, Latest.log had a sharing violation. I could not reproduce that again.
stderr.txt and stdout.txt are both getting closed at the moment of the crash, but are always both 0-bytes in size.
oolite.exe itself is closing via a Process Exit, with Exit Status: 3
7:50:14.7097262 AM oolite.exe 140 Process Exit SUCCESS Exit Status: 3, User Time: 4.7187500 seconds, Kernel Time: 0.7968750 seconds, Private Bytes: 106,393,600, Peak Private Bytes: 121,712,640, Working Set: 111,800,320, Peak Working Set: 126,636,032
From what I can gather, Exit Status: 3 means ERROR_PATH_NOT_FOUND "The system cannot find the path specified."
This same Process Exit also happens on another computer (using an onboard Intel video card) under similar conditions.
I am now desperate to figure out what file+path Oolite was attempting to access that triggered this error, because it seems like a missing dependency from the Windows install of Oolite.
This crash-to-desktop has happened to multiple people running various versions of windows...but strangely Mac and Linux versions of Oolite seem immune. It could be the case that Mac and Linux versions of Oolite are NOT immune, but just considerably less likely to trigger the CTD conditions.
The crash does not require misjumping while cloaked to trigger, those conditions just make the crash much more likely.
High movement speeds or instantaneous displacement of objects seem possibly related to the crash. For some, they only experience the CTD *IF* using my testing OXPs which do quick player ship movements or move/delete nearby npc ships.
Just to throw an idea around here, I find if I have had Oolite running for hours then it seems more prone to crashes and hangs. But if I close it and restart after every hour I now never get them with 1.76
Find out about the early influences of Fatleaf here. Also his OXP's!
Holds the Ooniversal record for "Thread Necromancy"
Some of my crashes occur within 1 minute of starting the program, maybe even under 30 seconds...if only that it takes me that long to load a savegame. From the moment the savegame is loaded till the moment the game crashes has been less than 10 seconds.
This is even after manually deleting Oolite's cache before starting oolite.exe
After a crash, additional crashes seem to happen quicker.
The crashes occur regardless of my shader setting. (off, simple, full)
The crashes happen on all my computers...not all of which use a Nvidia video card.
UPDATE:
Latest build Windows Trunk version 1.77.0.5057 still causing CTDs when doing misjumps while cloaked.
I had hoped the last 10 or so changes incidentally fixed my problem, since I don't know if they're graphics related or initialization related to arriving at a new system.
Is "Segmentation fault" just a catch-all error, or is there some research I can do on it to narrow down the root cause/s of these CTDs?
From the better-very-late-than-never department: the most likely cause of a segfault in oolite is trying to dereference a pointer that's already null, and/or trying to use an uninitialised pointer... it does fall under the dreaded memory management catch-all, and it's more-or-less the opposite to a memory leak... unfortunately both segfaults & memleaks are notoriously difficult to spot by simply reading the code.
Assuming you don't get any crashes when you're not cloaked, the problem will have to lie in the way some pointers are handled differently at all stages of a misjump... when cloacked as opposed to the standard uncloaked mode.
One of the most annoying CTDs associated with cloaking isn't during jumps/misjumps.
It's when I leave the main station -- I launch, cloak, pull up hard, and inject away from the main station. (Why am I doing this? Maybe it's because of a 100+ bounty on my head? Or I'm in a hurry to get out of mass-lock.) Before I've even changed my heading by 90 degrees...I'm often looking at my desktop. That takes less than 5 seconds from when I can first control my ship after launch.
If I had to guess, it's due to the weird code associated with targeting but then quickly forgetting cloaked ships. I've seen my hacked Thargoids doing it, (despite lacking random target changes in their "ATTACK_SHIP" section) which might explain why the CTD seems misjump related. The crash at the main station may likewise be due to the station itself (or a nearby police ship) doing a target check on my ship while it's cloaked.
I'll use this thread as the title fits - I just installed the latest nightly - trunk v1.77.0.5287 and got two CTDs out of three starts. The first was virgin Oolite, the second was with my usual OXP set - nothing in the logs, and my Windows diagnostic skills are negligible.
I would advise stilts for the quagmires, and camels for the snowy hills
And any survivors, their debts I will certainly pay. There's always a way!
Did the crashes happen before the spinning cobra at the very beginning?
If that's directed at me*, both CTDs happened shortly after the very first jump - the game actually started fine.
I was intending to go hunting for those longer-lasting hermits.
*if not, ignore
I would advise stilts for the quagmires, and camels for the snowy hills
And any survivors, their debts I will certainly pay. There's always a way!
Hmm, I'm not able to reproduce these crashes in vanilla, I'll add OXPs to see what happens.
The good news: it doesn't look like it's the modified system populator, after all: if the CTDs originate there, they would only happen immediately after the end of the tunnel effect.
The bad news: it looks like that just about every single source file has been modified since rev5250, if the crashes you're experiencing weren't there in rev5249, we might well have a needle/haystack situation...
