ORIGINAL: thewood1
Is that the same issue as the crashes?
[shrugs]I really don't know to be honest. The overshot message could be some sort of error recording for the devs on the event.
If it bugs you add a second entry for it.
Mike
[Fixed] Crashing JASSM & JASSM-ER
Moderator: MOD_Command
RE: Crashing JASSM & JASSM-ER
[shrugs]I really don't know to be honest. The overshot message could be some sort of error recording for the devs on the event.
If it bugs you add a second entry for it.
Mike
" You have to be realistic about these things." ~Logan Ninefingers
RE: Crashing JASSM & JASSM-ER
Not sure what you mean. The OP's message logs were showing crashes. I think were before they ever got to the target. Your pics look like a different issue.
RE: Crashing JASSM & JASSM-ER
ORIGINAL: thewood1
Not sure what you mean. The OP's message logs were showing crashes. I think were before they ever got to the target. Your pics look like a different issue.
Could be. Never know.
" You have to be realistic about these things." ~Logan Ninefingers
RE: Crashing JASSM & JASSM-ER
ORIGINAL: Eboreg
Playing at full time compression has a tendency to do that to cruise missiles when they hit rough terrain.
Just verified what you said for myself. Half of the JASSMs crash along the way, but only if you run at fastest speed. Didn't see a single overshoot, but that might depend on terrain.
Also wonder if PC specs matter on this as well. It might be just missing CPU cycles.
-
Tecmeister
- Posts: 27
- Joined: Sun Dec 10, 2006 11:14 pm
RE: Crashing JASSM & JASSM-ER
The fastest time compression I used for the original save was 2X. I may use 5X for a very short period, but I've probably used 5X less than 20 times since getting CMANO.
A decade of Blue Water service
RE: Crashing JASSM & JASSM-ER
It still might be lated to CPU cycles. If your system is a lower end system or configured to not run at its fastest speed, maybe its missing execution cycles.
Because when I run at 15x in .14 and .16, I don't get a single crash.
Because when I run at 15x in .14 and .16, I don't get a single crash.
-
KnightHawk75
- Posts: 1850
- Joined: Thu Nov 15, 2018 7:24 pm
RE: [Logged] Crashing JASSM & JASSM-ER
I spent some time trying investigating this. I've seen this before especially when moving missiles, it's sporadic though (just because you don't get it on one startup doesn't mean you will not on another), and once it starts or is around it stays around, and a game restart is required to clear up for me when it does happen. What caught my attention is it was in this same area the op's scene is in where I first experienced this last March or April, and once or twice since, and seemingly only in this area, and by area I mean 40-90N,20-60E.
TLDR: Very weird indeed!
Non TLDR:
As for 15x vs other timing I don't think that's it entirely. The _really tricky_ part of this problem, at least for me|my system, is being unable to constantly repo it on a fresh startup. It either happens "activates\triggers" or it doesn't, and on average for me it's only about 1:10 for me, maybe 1:8 if I flush standby ram first (though who knows if that really helped and I didn't just get lucky a few times).
Using the OP's scene I could identify when it was "active" or not and replicate it. It required doing nothing other than reloading the map in the editor from the recent files list. Also when active the issue will stay around if you load another scene (test rig attached with far less going on) or the OP's again, or create a new one,etc.
When the problem showed itself I started watching the if (calculated-unitAGL < 0) then crash the missile into the ground calc. As you might expect the problem was AGL turning up negative during lots of these compares (the gui had correct values till the point of it happening, as did the activeunit ASL wise it seemed). I was expecting to see small negatives, in amounts roughly equal to the "elevation jitter" across a flight path, figured if a thread was 'running behind' or something in updating or something, that could account for a small negative and crash the weapon.
That's _not_ what I saw though, instead yes sometimes they were small, but sometimes they were confusingly massive, even when something passed the < 0 check often the value evaluated was wildly wrong. One extreme example was one that actually passed the check, with an AGL of ~32kft (having been launched at ~42k), yet the 158A was actually flying at ~400ft and 60ft AGL (for an hour mind you as I kept refueling it cause it was one out 96 that refused to die I wanted to know what made it special) and the objects other properties said the same fly at ~400ft. It's like something told it you're asl is 32k and then flagged it to not be updated again (separate from what the gui was pulling from). Another head-scratch was on a 154-C1 launched over the sea at a land target, when it crashed over land for example the AGL in the calc was -2108 feet, when the land below it was ~100ft and elevation changes around it for next mile were ~0-50ft, and there was never anything it flew over higher than about 500 ft. The water it traveled over 10's of miles prior never exceeded ~-1500. Very strange.
I got lucky a couple times and happen to have one selected while it crashed, like 1/2 second before this it was reading fine, then suddenly -1783 agl in 1/2 a second.
Here's just another caught in the act (as you can see by age I kept him around awhile.)
A third dying a second after I moved it from land to sea, which had a habit of happening during that game instance:
An area where 99% of the time anything moved to it or launched through it died in a few seconds pretty darn reliably (but only on one startup instance - though I was trying this area because it's where I previously had problems ~6mo ago.):
Later plopped a b1 in there and launched 48 158'c, all 48 died in about 10 seconds or before exiting that area. I mention this area or water more generally because it'was interesting to watch missles decend to what should be ~30ft, but at around XXX they would insta-pop back up to ~2500, then head down again, insta-pop back up, rinse and repeat till they die. This happens when the problem is active over land too but watching over water is easier than land as there should be few if no corrections for changing elevation of the landscape that might explain movement. Weirder still is a test scene I made for that area didn't demonstrate it as screwy even when the problem was otherwise active in furture "triggered" restarts. Though the same test scene does still result in 1/2 or more dying elsewhere on their road to the target, at least that part is repeatable between at least 5 "triggered" restarts so far where I've retested with same\very similar results.
From poking around it's as if the figure that's being fed to that unit-agl side of the equation wasn't being updated(or the update to it was being flagged to be bypassed and a stale value used, even then though I couldn't account for some of the actual negative values in there. What ever was going on ultimately the value compared was not correct for the state of the unit at the time, most of the time not even close.
If you're wondering about the popup it's just a weapon tracker system, where every second it tracks all the weapons I'm interested in and keeping running track of the last 15 seconds of locations. I tried sending some over the exact final steps of someone who crashed on land and it didn't replicate a crash on exactly the same path at the same time reliably so it didn't look 'exact' lat|lon specific. Interestingly doing the same tests away from the Kola, over in the Gulf of Mexico zig zagging out to depth and then to coastal then inland to targets around the contiguous states did NOT produce the same results when the problem was active. All those launches went without issue, same over in the Hawaii area, same over canada\AK\fareast Russia, or launches from cali to midwest over mountains. Didn't matter if it was 30 weapons active or 800 weapons active. I used several hundreds of missiles at a time traveling thousands of nm to spot check and cover a lot of
ground, nothing - except for in 40-90|20-60 and _only_ when the problem is "active" for me. It's not restricted to just the kola area, got several hits south of it as well, and some east of it. Makes me wonder if this does have an element of "e20n90.bgd" to it somehow some way.
On that front, shortly after starting op's scene sometimes I would get these in a pairs in once instance like 12 in another only 6.
1/28/2021 10:29:15 PM -- B1147.16 -- Index was outside the bounds of the array.
Exception: Index was outside the bounds of the array.
Stack Trace: at ....(Int16 , Int16 )
Call Stack & Error details:
Error at 200494, Index was outside the bounds of the array.
1/28/2021 10:29:15 PM -- B1147.16 -- Index was outside the bounds of the array.
Exception: Index was outside the bounds of the array.
Stack Trace: at ....(Int16 , Int16 , Int16 )
Call Stack & Error details:
Error at 200496, Index was outside the bounds of the array.
By sometimes I mean only on initial|first startup of the game where the problem was "active|triggered".
Those relate to lat|lon elevation cache array requests\lookup-and-fills I think. As for data that was fed to those two functions the first I couldn't tell you but the later one one occasion where I caught it was trying to index what I think is effectively a cache[latrow][loncol] it was trying to feed 5999|4445 to an array that only had the size of 7200x3600 or 3601 at the time. Almost like the request was based on one tile, but the cache being accessed was from another?? idk i couldn't figure out how it happened, the unit I think involved was a sat. I got those on two different startup per my logs, but soon as I wanted to dig into them more they never happened again on successive restarts where the overall issue was active, at least not yet.
As already alluded too and is probably obvious by now it's not restricted to 158A|B|C's I was able to get some 154C-1's (though it happened far less ~6-7 out of 384 fired in one long series) and 109E|I's to generate it too as well as kh-101, and as-22's, pretty sure it can effect at least anything that terrain follows in some fashion, 109Z-FastHawks for example didn't have the problem since they cruise at like 100k. I tested some aircraft flying at min alt with and without TG on, no crashes,on the startups when problem was 'active'. 15x didn't seem to make it happen more often for me. I got just as many on avg overall in 1x\2x as I did in 5\x15x, though I didn't keep a recorded table I'd actually say I got few more in 1x 2x 5x than 15x. I think that could just be a product of timing such 'where' the elevation check happens to be done. Though eventually if you keep your missiles in the air (refueling them with lua for testing purposes and moving them around, particularly to the right spots) they usually _all_ die in the end when problem is active, just a matter of where and when, just don't move them so far that they are technically out of range or they'll peter out. Oh and sea launched or air launched makes no difference when it's active it seems.
Now why does it appear to not always happen?
I don't know. FWIW I probably have one of the slower rigs out there winSrv2008r2 x64 us-eng i950 24gb and even at 2x,5x,15x,flame, I couldn't "trigger" it to happen on most startups. The few times it did show itself was after fresh restart (and creating new scene button to then load scene). This matches with my own experiences with this issue in the past, seemingly random and determined at startup, and cleared by a restart. If I was to speculate it almost seems like a product of how things end up scheduled during startup somehow (thread wise?)that can screw up perhaps the assumed order of events, and less about raw cpu capacity. Or maybe something to do with any pre-caching|setup of elevation data? Running it with only 1,2,3, cores made no difference in trying to repo it that I could find, running in low priority made no difference,suspending and un-suspending main thread didn't produce it or clear it up (not that anyone should be doing these things lol).
I'm stumped on how to purposely cause it to get into the state, total luck of the draw on startup. Once it's there it's fairly easy to repo but only inside one geographic area in my experiences. Now that doesn't mean it doesn't happen with other areas,as I only tested a few of the 33 regions during the few triggered starts I managed to get out of probably 100 restarts over a couple days. I did confirm there is nothing screwy with the SRTM30Plus data being pulled itself, the values returned when there is no exception are valid and appear correct for the lat|lon rows\cols being inserted into the cache when records were not yet cached, so it's not like there are dead spots or something in the data causing problems,at least not in the file.
I doubt it will help but I have full and mini dumps from the process while the problem state existed snapped shortly after the op's scene starts if devs want it, doubt it's that useful though. I did not focus much on the additionally mentioned 'overshot target' issue up thread, though I did see some in testing it wasn't more than a few that I just chocked up to rng, as I did the occasional legit rng malfunction so long as it happened near the target, but most what I was doing didn't involving letting munitions get to their targets in the first place.
On occasions you'll get one of these I think if you have a dead missile still selected I think, no biggy but figured it was worth mentioning.
-- B1147.16 -- Object reference not set to an instance of an object.
Exception: Object reference not set to an instance of an object.
Stack Trace: at Command.UnitEMCONViewModel.?()
at Command.UnitEMCON_WPF.(ActiveUnit theUnit)
at Command.RightColumnWPF.(Scenario , Side , Unit )
Call Stack & Error details:
Error at 999999,
Attached another scene that when the problem happens you'll lose about 50-75% before the target depending on timing\jitter, but the path they crash on is pretty darn consistent overall. Though the op's is better for knowing you have the problem in the first minute or two, this one can take till they hit the coastal mountain region and the 19.9x to ~20.x' cross over, also it has far less going on to filter through if debugging and the units are customized for easier|further testing. It's setup to drop ref points on every destruction and message you but you
can turn that off in SA screen.
Some crash distribution screenshots:
Question for anyone who's had this happen:
When this happens to you has it ever happened outside 40->90N & 20->60E?
Does OP or others have this happen every time they start the game or is it like my system where it's a dice-roll?
Additionally when it happens is anyone else seeing those array bounds messages in the log (or anything else in the log) or were those just a me thing (and not even consistently a me thing at that)?
TLDR: Very weird indeed!
Non TLDR:
As for 15x vs other timing I don't think that's it entirely. The _really tricky_ part of this problem, at least for me|my system, is being unable to constantly repo it on a fresh startup. It either happens "activates\triggers" or it doesn't, and on average for me it's only about 1:10 for me, maybe 1:8 if I flush standby ram first (though who knows if that really helped and I didn't just get lucky a few times).
Using the OP's scene I could identify when it was "active" or not and replicate it. It required doing nothing other than reloading the map in the editor from the recent files list. Also when active the issue will stay around if you load another scene (test rig attached with far less going on) or the OP's again, or create a new one,etc.
When the problem showed itself I started watching the if (calculated-unitAGL < 0) then crash the missile into the ground calc. As you might expect the problem was AGL turning up negative during lots of these compares (the gui had correct values till the point of it happening, as did the activeunit ASL wise it seemed). I was expecting to see small negatives, in amounts roughly equal to the "elevation jitter" across a flight path, figured if a thread was 'running behind' or something in updating or something, that could account for a small negative and crash the weapon.
That's _not_ what I saw though, instead yes sometimes they were small, but sometimes they were confusingly massive, even when something passed the < 0 check often the value evaluated was wildly wrong. One extreme example was one that actually passed the check, with an AGL of ~32kft (having been launched at ~42k), yet the 158A was actually flying at ~400ft and 60ft AGL (for an hour mind you as I kept refueling it cause it was one out 96 that refused to die I wanted to know what made it special) and the objects other properties said the same fly at ~400ft. It's like something told it you're asl is 32k and then flagged it to not be updated again (separate from what the gui was pulling from). Another head-scratch was on a 154-C1 launched over the sea at a land target, when it crashed over land for example the AGL in the calc was -2108 feet, when the land below it was ~100ft and elevation changes around it for next mile were ~0-50ft, and there was never anything it flew over higher than about 500 ft. The water it traveled over 10's of miles prior never exceeded ~-1500. Very strange.
I got lucky a couple times and happen to have one selected while it crashed, like 1/2 second before this it was reading fine, then suddenly -1783 agl in 1/2 a second.
Here's just another caught in the act (as you can see by age I kept him around awhile.)
A third dying a second after I moved it from land to sea, which had a habit of happening during that game instance:
An area where 99% of the time anything moved to it or launched through it died in a few seconds pretty darn reliably (but only on one startup instance - though I was trying this area because it's where I previously had problems ~6mo ago.):
Later plopped a b1 in there and launched 48 158'c, all 48 died in about 10 seconds or before exiting that area. I mention this area or water more generally because it'was interesting to watch missles decend to what should be ~30ft, but at around XXX they would insta-pop back up to ~2500, then head down again, insta-pop back up, rinse and repeat till they die. This happens when the problem is active over land too but watching over water is easier than land as there should be few if no corrections for changing elevation of the landscape that might explain movement. Weirder still is a test scene I made for that area didn't demonstrate it as screwy even when the problem was otherwise active in furture "triggered" restarts. Though the same test scene does still result in 1/2 or more dying elsewhere on their road to the target, at least that part is repeatable between at least 5 "triggered" restarts so far where I've retested with same\very similar results.
From poking around it's as if the figure that's being fed to that unit-agl side of the equation wasn't being updated(or the update to it was being flagged to be bypassed and a stale value used, even then though I couldn't account for some of the actual negative values in there. What ever was going on ultimately the value compared was not correct for the state of the unit at the time, most of the time not even close.
If you're wondering about the popup it's just a weapon tracker system, where every second it tracks all the weapons I'm interested in and keeping running track of the last 15 seconds of locations. I tried sending some over the exact final steps of someone who crashed on land and it didn't replicate a crash on exactly the same path at the same time reliably so it didn't look 'exact' lat|lon specific. Interestingly doing the same tests away from the Kola, over in the Gulf of Mexico zig zagging out to depth and then to coastal then inland to targets around the contiguous states did NOT produce the same results when the problem was active. All those launches went without issue, same over in the Hawaii area, same over canada\AK\fareast Russia, or launches from cali to midwest over mountains. Didn't matter if it was 30 weapons active or 800 weapons active. I used several hundreds of missiles at a time traveling thousands of nm to spot check and cover a lot of
ground, nothing - except for in 40-90|20-60 and _only_ when the problem is "active" for me. It's not restricted to just the kola area, got several hits south of it as well, and some east of it. Makes me wonder if this does have an element of "e20n90.bgd" to it somehow some way.
On that front, shortly after starting op's scene sometimes I would get these in a pairs in once instance like 12 in another only 6.
1/28/2021 10:29:15 PM -- B1147.16 -- Index was outside the bounds of the array.
Exception: Index was outside the bounds of the array.
Stack Trace: at ....(Int16 , Int16 )
Call Stack & Error details:
Error at 200494, Index was outside the bounds of the array.
1/28/2021 10:29:15 PM -- B1147.16 -- Index was outside the bounds of the array.
Exception: Index was outside the bounds of the array.
Stack Trace: at ....(Int16 , Int16 , Int16 )
Call Stack & Error details:
Error at 200496, Index was outside the bounds of the array.
By sometimes I mean only on initial|first startup of the game where the problem was "active|triggered".
Those relate to lat|lon elevation cache array requests\lookup-and-fills I think. As for data that was fed to those two functions the first I couldn't tell you but the later one one occasion where I caught it was trying to index what I think is effectively a cache[latrow][loncol] it was trying to feed 5999|4445 to an array that only had the size of 7200x3600 or 3601 at the time. Almost like the request was based on one tile, but the cache being accessed was from another?? idk i couldn't figure out how it happened, the unit I think involved was a sat. I got those on two different startup per my logs, but soon as I wanted to dig into them more they never happened again on successive restarts where the overall issue was active, at least not yet.
As already alluded too and is probably obvious by now it's not restricted to 158A|B|C's I was able to get some 154C-1's (though it happened far less ~6-7 out of 384 fired in one long series) and 109E|I's to generate it too as well as kh-101, and as-22's, pretty sure it can effect at least anything that terrain follows in some fashion, 109Z-FastHawks for example didn't have the problem since they cruise at like 100k. I tested some aircraft flying at min alt with and without TG on, no crashes,on the startups when problem was 'active'. 15x didn't seem to make it happen more often for me. I got just as many on avg overall in 1x\2x as I did in 5\x15x, though I didn't keep a recorded table I'd actually say I got few more in 1x 2x 5x than 15x. I think that could just be a product of timing such 'where' the elevation check happens to be done. Though eventually if you keep your missiles in the air (refueling them with lua for testing purposes and moving them around, particularly to the right spots) they usually _all_ die in the end when problem is active, just a matter of where and when, just don't move them so far that they are technically out of range or they'll peter out. Oh and sea launched or air launched makes no difference when it's active it seems.
Now why does it appear to not always happen?
I don't know. FWIW I probably have one of the slower rigs out there winSrv2008r2 x64 us-eng i950 24gb and even at 2x,5x,15x,flame, I couldn't "trigger" it to happen on most startups. The few times it did show itself was after fresh restart (and creating new scene button to then load scene). This matches with my own experiences with this issue in the past, seemingly random and determined at startup, and cleared by a restart. If I was to speculate it almost seems like a product of how things end up scheduled during startup somehow (thread wise?)that can screw up perhaps the assumed order of events, and less about raw cpu capacity. Or maybe something to do with any pre-caching|setup of elevation data? Running it with only 1,2,3, cores made no difference in trying to repo it that I could find, running in low priority made no difference,suspending and un-suspending main thread didn't produce it or clear it up (not that anyone should be doing these things lol).
I'm stumped on how to purposely cause it to get into the state, total luck of the draw on startup. Once it's there it's fairly easy to repo but only inside one geographic area in my experiences. Now that doesn't mean it doesn't happen with other areas,as I only tested a few of the 33 regions during the few triggered starts I managed to get out of probably 100 restarts over a couple days. I did confirm there is nothing screwy with the SRTM30Plus data being pulled itself, the values returned when there is no exception are valid and appear correct for the lat|lon rows\cols being inserted into the cache when records were not yet cached, so it's not like there are dead spots or something in the data causing problems,at least not in the file.
I doubt it will help but I have full and mini dumps from the process while the problem state existed snapped shortly after the op's scene starts if devs want it, doubt it's that useful though. I did not focus much on the additionally mentioned 'overshot target' issue up thread, though I did see some in testing it wasn't more than a few that I just chocked up to rng, as I did the occasional legit rng malfunction so long as it happened near the target, but most what I was doing didn't involving letting munitions get to their targets in the first place.
On occasions you'll get one of these I think if you have a dead missile still selected I think, no biggy but figured it was worth mentioning.
-- B1147.16 -- Object reference not set to an instance of an object.
Exception: Object reference not set to an instance of an object.
Stack Trace: at Command.UnitEMCONViewModel.?()
at Command.UnitEMCON_WPF.(ActiveUnit theUnit)
at Command.RightColumnWPF.(Scenario , Side , Unit )
Call Stack & Error details:
Error at 999999,
Attached another scene that when the problem happens you'll lose about 50-75% before the target depending on timing\jitter, but the path they crash on is pretty darn consistent overall. Though the op's is better for knowing you have the problem in the first minute or two, this one can take till they hit the coastal mountain region and the 19.9x to ~20.x' cross over, also it has far less going on to filter through if debugging and the units are customized for easier|further testing. It's setup to drop ref points on every destruction and message you but you
can turn that off in SA screen.
Some crash distribution screenshots:
Question for anyone who's had this happen:
When this happens to you has it ever happened outside 40->90N & 20->60E?
Does OP or others have this happen every time they start the game or is it like my system where it's a dice-roll?
Additionally when it happens is anyone else seeing those array bounds messages in the log (or anything else in the log) or were those just a me thing (and not even consistently a me thing at that)?
- Attachments
-
- TestRig_Cr.._public2.zip
- (135.62 KiB) Downloaded 21 times
RE: [Logged] Crashing JASSM & JASSM-ER
Not sure what this means but here goes...
I have run the test rig 24 times. 12 with my PC set at maximum performance. 12 with power-saving enabled.
At max, the CPU is running about 4.8 GHz ad the 2080 GPU provides max performance. Not a single missile crashed up to the point they were shot down.
At energy saver, with the CPU running between 3.0 GHz and 4.5 GHZ and Intel GPU, I had one missile crash in every run through. The rest made it to get shot down. The crashes don't happen in the same spot, but are always past the halfway point to the target. It is eerily consistent with the one crashed missile in each run.
I'm going to run it on my old laptop with an older i7 and a 1660 GPU to see what happens. I have a theory or two and will see if the older laptop aligns with those thoughts.
I have run the test rig 24 times. 12 with my PC set at maximum performance. 12 with power-saving enabled.
At max, the CPU is running about 4.8 GHz ad the 2080 GPU provides max performance. Not a single missile crashed up to the point they were shot down.
At energy saver, with the CPU running between 3.0 GHz and 4.5 GHZ and Intel GPU, I had one missile crash in every run through. The rest made it to get shot down. The crashes don't happen in the same spot, but are always past the halfway point to the target. It is eerily consistent with the one crashed missile in each run.
I'm going to run it on my old laptop with an older i7 and a 1660 GPU to see what happens. I have a theory or two and will see if the older laptop aligns with those thoughts.
-
KnightHawk75
- Posts: 1850
- Joined: Thu Nov 15, 2018 7:24 pm
RE: [Logged] Crashing JASSM & JASSM-ER
@thewood1
Hmm could be interesting.
Does your theory involving initially manually setting clock speed to lower than 100% stepping, and then later changing it once the game is fully loaded but before scene starts to 100%? If so I tried that,one and only one time (I was randomly trying all kinds of shit I didn't bother mentioning above), which seemed to make no difference (that startup everything worked fine), so I moved on and didn't really look more at that. _But_ if you find something there I'm happy to do a bunch more runs like that cause I had a theory about fluxing speed. By default on my system during ~95% of my testing I use(d) my normal custom plan (allows cpu steeping to dip to ~65% or ~2ghz but no lower).
Maybe I'll do 10 runs of testrig one at hard set ~2.1ghz, 10 runs at hard set max ~3.07ghz, and 10 runs at letting it flux more like 50-100% (I think ~1600 is lowest speed stepping for me so setting lower is pointless) and see if I get anything interesting.
Hmm could be interesting.
Does your theory involving initially manually setting clock speed to lower than 100% stepping, and then later changing it once the game is fully loaded but before scene starts to 100%? If so I tried that,one and only one time (I was randomly trying all kinds of shit I didn't bother mentioning above), which seemed to make no difference (that startup everything worked fine), so I moved on and didn't really look more at that. _But_ if you find something there I'm happy to do a bunch more runs like that cause I had a theory about fluxing speed. By default on my system during ~95% of my testing I use(d) my normal custom plan (allows cpu steeping to dip to ~65% or ~2ghz but no lower).
Maybe I'll do 10 runs of testrig one at hard set ~2.1ghz, 10 runs at hard set max ~3.07ghz, and 10 runs at letting it flux more like 50-100% (I think ~1600 is lowest speed stepping for me so setting lower is pointless) and see if I get anything interesting.
RE: [Logged] Crashing JASSM & JASSM-ER
Hi,
This is definitively a weird issue, I could not reproduce it a single time on my side.
Thanks a lot, KnightHawk for this detailed investigation.
200494 and 200496 Are worth investigating since it is indeed the get/set for the cached elevation.
the 5999|4445 values that get fed is a concerning issue and it is possible that the converted grid coordinates from long/lat gets messed up somewhere while remaining unnoticed until it overflows the array.
But, as mentioned, the problem is that I can't reproduce it, a dirty sanity check could patch it, but that might just hide the root issue.
Feel free to send me the raw process dump. At that point, any information is welcomed.
-Geoffroy
This is definitively a weird issue, I could not reproduce it a single time on my side.
Thanks a lot, KnightHawk for this detailed investigation.
200494 and 200496 Are worth investigating since it is indeed the get/set for the cached elevation.
the 5999|4445 values that get fed is a concerning issue and it is possible that the converted grid coordinates from long/lat gets messed up somewhere while remaining unnoticed until it overflows the array.
But, as mentioned, the problem is that I can't reproduce it, a dirty sanity check could patch it, but that might just hide the root issue.
Feel free to send me the raw process dump. At that point, any information is welcomed.
-Geoffroy
RE: [Logged] Crashing JASSM & JASSM-ER
PS : Could you also send me your own e20n90 bgd files ?
Maybe a good test would be to have 4 or more firing units at the edge of each side of this geographical zone. ((lat > 20 && < 60) and long > 40) And see if we get the expected pattern.
If that confirms, that would make a very strong correlation.
Maybe a good test would be to have 4 or more firing units at the edge of each side of this geographical zone. ((lat > 20 && < 60) and long > 40) And see if we get the expected pattern.
If that confirms, that would make a very strong correlation.
-
KnightHawk75
- Posts: 1850
- Joined: Thu Nov 15, 2018 7:24 pm
RE: [Logged] Crashing JASSM & JASSM-ER
@Geoffropi
...figures I stored it in cmo/temp and it got whacked..sigh that's ok I snapped a fresh one just now.
Sure, I can zip all that stuff up and upload it somewhere for you and pm you, the full dump is probably like 250mb compressed so may take a little time for me to get it uploaded, the rest (mini and data should be relatively small in comparison).
When you say your own, I assume you mean the 32bit int ones from the game's folder, and not the 16bit raw ones I grabbed from topex.ucsd.edu just to triple check\compare the data itself (it was not different btw and row\col calcs all worked out same too after adjusting for shorts, no headers, and little vs big endian).
edit: sent
...figures I stored it in cmo/temp and it got whacked..sigh that's ok I snapped a fresh one just now.
Sure, I can zip all that stuff up and upload it somewhere for you and pm you, the full dump is probably like 250mb compressed so may take a little time for me to get it uploaded, the rest (mini and data should be relatively small in comparison).
When you say your own, I assume you mean the 32bit int ones from the game's folder, and not the 16bit raw ones I grabbed from topex.ucsd.edu just to triple check\compare the data itself (it was not different btw and row\col calcs all worked out same too after adjusting for shorts, no headers, and little vs big endian).
edit: sent
-
KnightHawk75
- Posts: 1850
- Joined: Thu Nov 15, 2018 7:24 pm
RE: [Logged] Crashing JASSM & JASSM-ER
So did 48 starts with different power management settings:
All were done in windowed mode, after pressing > screen was minimized.
60-120second wait between each restart, where applicable to verify proc was leveled down to 1.6 or 2.0ghz
All tests monitored after startup and pressing go procs were all at 3.06ghz throughout the test run duration.
n indicates normal (no problem instance)
x indicates runs where it happened as I've past experienced it (lots of crashes in roughly same places).
* indicates runs where it happened but not as past experienced, got a 1 single crash about ~25nm out from target. might be same result thewood was getting perhaps.
** indicates runs where it happened as I've past experienced, but I may have ruined the purity of the run being equal to the others by having a mp4 playing in vlc before\during exe startup, and loaded op's scene first before my own testrig, I doubt it mattered but wanted to note it (I simply forgot I wasn't done yet).
I don't see any consistency out of it all.
Yesterday I did bunch of testing on one "triggered" instance as it relates to 20-60E 40-90N.
Did a mix of firing from with-in it to somewhere inside it, partially in it (inside lat outside lon), from outside to somewhere with-in, outside to somewhere outside, and a couple inside-outs.
A smattering of screens from those runs.
I start with my usual "testrig" version run ensuring things are in screwy mode. I get the usual results from a launch from inside lat, to inside lat|lon.
4 shots from east of 60E but inside 40-90N.
The first screen is for context for the zoomed other 3 and shows run1 results (most north run).
These all had crashes shortly after crossing 60E, did not cross water or negative territory that I know of in latter 3.
This guy was fired from outside the suspect lat|lon, involved water and had crashes, though not shortly after.
Same target from inside suspect lat| outside lon, involved water and had NO crashes, one of the most unexpected results and goes toward disproving lat|lon theory.
Same target from outside long,inside lat, lots of crashes and quickly, but not near a "line" so to speak.
Same target ... just a little further north to take the alps out of it, basically same result.
Same target ... just a little further north to add water to it, crashes but hardly similar.
Same target from outside lat and long, crashes start after crossover on land, water involved.
Target moved outside long,inside lat. fired on from outside lat|long, water involved, crashes north of 40N.
Same target ...same firing pt, slightly different path, basically same result shortly after landfal > 40N mass crashes.
Target moved outside of both long and lat... fired on from outside lat|lon, water involved, zero crashes.
Now for a little something different
Inside lat|long firing on something outside lon but inside lat... water involved, mass crashes.
(Missing screen shot, I did one from fully inside to one fully outside and got crashes in spots inside... forgot to snap pic on that one)
For this one I did two firing units (clones), both firing form outside long, but inside lat,one at target inside 60L one outside 60L. both paths involve at least some momentary water. kinda interesting one gets lots of crashes one gets none.
Here we have the same two units firing from outside E20-60 N40-90 at something inside, lots of crashes.
The path might seem slight off cause I moved the target slightly to put more land in front of it just after launch but assure you outside the range ring those are crashes and not destruction(s).
Moving on to random other area where we fire from outside lat|long, at two targets, one inside lat, one outside lat. crashs on the inside one.
Here we have two launches one from both inside lat but not long,one outside lat and long, toward one inside, no water... no crashes. ???
Again seems one for the disprove column as it bucked the trend.
For giggle I re-ran that one again moving the target such that water had to be crossed.
I also slight moved the target back more into land shortly after launch as I had it literally on the coast which defeated the purpose of what I wanted to see (if water ie negative elevation cross-over made a difference). It definitely seemed too get a different result.
I did a couple sanity check runs across the USA\CA, and Africa, no crashes. no screens cause it wasn't any different than previously mentioned.
What does any of this mean, hard for me to say exactly. Hopefully it gives an idea of why I brought up that tile even if I think 2 of these screen shots argue against it being involved. Thought then it might just be crossing negative elevation, but then other screen disprove that so stumped again. [&:]
Code: Select all
1 2 3 4 5 6 7 8 9 10 11 12
2ghz locked n n n n n n n n n n n n
3ghz locked n x x* n n n n x* n n n x*
1.6-3ghz flux allowed n n n n n n n n n n n n
2.0-3ghz flux allowed n n n n n n n n n x n x**
60-120second wait between each restart, where applicable to verify proc was leveled down to 1.6 or 2.0ghz
All tests monitored after startup and pressing go procs were all at 3.06ghz throughout the test run duration.
n indicates normal (no problem instance)
x indicates runs where it happened as I've past experienced it (lots of crashes in roughly same places).
* indicates runs where it happened but not as past experienced, got a 1 single crash about ~25nm out from target. might be same result thewood was getting perhaps.
** indicates runs where it happened as I've past experienced, but I may have ruined the purity of the run being equal to the others by having a mp4 playing in vlc before\during exe startup, and loaded op's scene first before my own testrig, I doubt it mattered but wanted to note it (I simply forgot I wasn't done yet).
I don't see any consistency out of it all.
Yesterday I did bunch of testing on one "triggered" instance as it relates to 20-60E 40-90N.
Did a mix of firing from with-in it to somewhere inside it, partially in it (inside lat outside lon), from outside to somewhere with-in, outside to somewhere outside, and a couple inside-outs.
A smattering of screens from those runs.
I start with my usual "testrig" version run ensuring things are in screwy mode. I get the usual results from a launch from inside lat, to inside lat|lon.
4 shots from east of 60E but inside 40-90N.
The first screen is for context for the zoomed other 3 and shows run1 results (most north run).
These all had crashes shortly after crossing 60E, did not cross water or negative territory that I know of in latter 3.
This guy was fired from outside the suspect lat|lon, involved water and had crashes, though not shortly after.
Same target from inside suspect lat| outside lon, involved water and had NO crashes, one of the most unexpected results and goes toward disproving lat|lon theory.
Same target from outside long,inside lat, lots of crashes and quickly, but not near a "line" so to speak.
Same target ... just a little further north to take the alps out of it, basically same result.
Same target ... just a little further north to add water to it, crashes but hardly similar.
Same target from outside lat and long, crashes start after crossover on land, water involved.
Target moved outside long,inside lat. fired on from outside lat|long, water involved, crashes north of 40N.
Same target ...same firing pt, slightly different path, basically same result shortly after landfal > 40N mass crashes.
Target moved outside of both long and lat... fired on from outside lat|lon, water involved, zero crashes.
Now for a little something different
Inside lat|long firing on something outside lon but inside lat... water involved, mass crashes.
(Missing screen shot, I did one from fully inside to one fully outside and got crashes in spots inside... forgot to snap pic on that one)
For this one I did two firing units (clones), both firing form outside long, but inside lat,one at target inside 60L one outside 60L. both paths involve at least some momentary water. kinda interesting one gets lots of crashes one gets none.
Here we have the same two units firing from outside E20-60 N40-90 at something inside, lots of crashes.
The path might seem slight off cause I moved the target slightly to put more land in front of it just after launch but assure you outside the range ring those are crashes and not destruction(s).
Moving on to random other area where we fire from outside lat|long, at two targets, one inside lat, one outside lat. crashs on the inside one.
Here we have two launches one from both inside lat but not long,one outside lat and long, toward one inside, no water... no crashes. ???
Again seems one for the disprove column as it bucked the trend.
For giggle I re-ran that one again moving the target such that water had to be crossed.
I also slight moved the target back more into land shortly after launch as I had it literally on the coast which defeated the purpose of what I wanted to see (if water ie negative elevation cross-over made a difference). It definitely seemed too get a different result.
I did a couple sanity check runs across the USA\CA, and Africa, no crashes. no screens cause it wasn't any different than previously mentioned.
What does any of this mean, hard for me to say exactly. Hopefully it gives an idea of why I brought up that tile even if I think 2 of these screen shots argue against it being involved. Thought then it might just be crossing negative elevation, but then other screen disprove that so stumped again. [&:]
-
SteveMcClaire
- Posts: 4344
- Joined: Mon Nov 19, 2007 9:31 pm
RE: [Logged] Crashing JASSM & JASSM-ER
The issue with the missiles overshooting the target at max sim speed will be fixed in the next update.
I could not reproduce the missiles crashing into the ground but I did find and fix an issue that I believe may be the cause. This change will also be in the next update.
I could not reproduce the missiles crashing into the ground but I did find and fix an issue that I believe may be the cause. This change will also be in the next update.
-
SteveMcClaire
- Posts: 4344
- Joined: Mon Nov 19, 2007 9:31 pm
RE: [Logged] Crashing JASSM & JASSM-ER
Hi KnightHawk75,
If you still have a test scenario where you reliably see missile crashes please post it here.
Thanks!
If you still have a test scenario where you reliably see missile crashes please post it here.
Thanks!
-
KnightHawk75
- Posts: 1850
- Joined: Thu Nov 15, 2018 7:24 pm
RE: [Logged] Crashing JASSM & JASSM-ER
ORIGINAL: SteveMcClaire
Hi KnightHawk75,
If you still have a test scenario where you reliably see missile crashes please post it here.
Thanks!
"Reliably" with this issue was always the problem as previously mentioned, but I'll try the op's and on posted in #28 previously posted a couple dozen times with the update when it comes, hopefully the fixes will make it not manifest anymore. Thanks for looking into this and trying to address it.
RE: [Logged] Crashing JASSM & JASSM-ER
The best way I fouond to see it is slowing your computer a little. At max performance, I never saw it. Once I went to a low power option on my CPU, its started showing up.
-
KnightHawk75
- Posts: 1850
- Joined: Thu Nov 15, 2018 7:24 pm
RE: [Logged] Crashing JASSM & JASSM-ER
ORIGINAL: thewood1
The best way I fouond to see it is slowing your computer a little. At max performance, I never saw it. Once I went to a low power option on my CPU, its started showing up.
That wasn't my experience however (post #34), yours (or others) mileage may vary though.
RE: [Logged] Crashing JASSM & JASSM-ER
Actully, I went back and checked my notes. I didn't slow down my main laptop. I tried it on two different ones. My main i9-10900k had no issues running at full performance. My i7-1065G7 Surface Book had missiles disappearing. I saw this consistently over at least 10 runs on each.