All this chatter, and no update on Sabiyhan...
“Sabiyhan” System Search Crash Mystery
- Thread starter Danger Investigates
- Start date
It's not the audio engine. You're not understanding what your tools are showing you. I don't know where the line is drawn here so let's talk about Shadow of the Tomb Raider where this post by Wobbler might be similar to what you're seeing:
Game crash to desktop after ~2 hours :: Shadow of the Tomb Raider Tech support
https://drive.google.com/open?id=1jfbCfDqcCcMVJVQe3PgBBpyzP0wBFCvh First dump (22:05 12.09.2018) - first launch and play ~2 hours with old GPU driver, then CTD Update GPU driver to 399.24 Second dump (17:21 13.09) - try to continue autosave from first play - CTD Third (20:52 13.09) - load from...
Those AK::WriteBytesMem symbols in the trace are obviously nothing to do with those methods as given the offsets they would be megabytes in size and calling into themselves at random locations. The reason this happens is AK's wwise library is often statically linked and has symbols in it and the rest of the code does not, so when tools write out the nearest symbol you get something miles away from where rip was, in a completely different company's code. People who know just enough to arrive at the wrong answer then assume that their game crashes are related to audio. This leads to a lot of bad advice, like if you google those symbols you'll find many people being told to reinstall audio drivers to fix their game crashing based on others drawing the wrong conclusions from the output of tools they aren't familiar with.
This is very true, stemming from its roots in Diablo.
aha. for a seconds my cow expectations went through the roof.
It's not the audio engine. You're not understanding what your tools are showing you. I don't know where the line is drawn here so let's talk about Shadow of the Tomb Raider where this post by Wobbler might be similar to what you're seeing:
Game crash to desktop after ~2 hours :: Shadow of the Tomb Raider Tech support
https://drive.google.com/open?id=1jfbCfDqcCcMVJVQe3PgBBpyzP0wBFCvh First dump (22:05 12.09.2018) - first launch and play ~2 hours with old GPU driver, then CTD Update GPU driver to 399.24 Second dump (17:21 13.09) - try to continue autosave from first play - CTD Third (20:52 13.09) - load from...steamcommunity.com
Those AK::WriteBytesMem symbols in the trace are obviously nothing to do with those methods as given the offsets they would be megabytes in size and calling into themselves at random locations. The reason this happens is AK's wwise library is often statically linked and has symbols in it and the rest of the code does not, so when tools write out the nearest symbol you get something miles away from where rip was, in a completely different company's code. People who know just enough to arrive at the wrong answer then assume that their game crashes are related to audio.
Thanks.
I see a warning and a bunch of potentially problematic annotations on some of the symbols. So, yeah maybe it's not correct enough to say much.
And as I said, even if it's indeed resulting in crashing the audio code, something else might just be messing things up ahead of that.
Yeah, lots of website filled up with names of dlls, engine function names, and pitching you on installing all sort of weird junk ("repair your pc"). No one should do that...
Last edited:
"It depends™" entirely on what it's doing under the hood. Searching for invalid/nonexistent data usually doesn't cause failure (imagine if google crashed every time you searched for something which didn't exist)... but trying to do something with nonexistent data will cause a crash (e.g for an addition requiring integers, 1+2 works, but 1+<null> would not)... so if that first thing is trying something with audio, then that's what you'll see fail, not that some index was corrupt. If we go one step further, maybe for efficiencies sake, we're just grabbing data and assuming it's correct and just passing non-audio data to an audio engine. That's probably going to make the audio engine crash too.
tl;dr invalid/nonexistent data is still data, so trying to fetch it isn't usually a problem.
But as @Christopher Roberto is kinda getting at saying and I've been alluding to, crashes are ungraceful, and if you fetch data at some random memory address and try to do something with it, you're going to get all sorts of weird outcomes that can make a trace which has absolutely nothing to do with what actually went wrong.
Last edited:
![[PS4] Filthymick420](https://forums-cdn.zaonce.net/data/avatars/m/201/201444.jpg?1555738739){kind=avatar}
Time to start filling up inventory with thargoid probes/sensors, trinkets of hidden fortune and every other suspicious 'commodity' and resume search attempts
if i wanted to hide something in the game and have certain items or starting locations be a factor in unlocking it, i wouldn't make the game crash when you were wrong, i'd just make it do nothing. Then as a player you'd have no idea if you even had the search term correct.
then again, if i wanted (or had) to hide secret system names in the client i'd hash them with something like md5sum or better. I wouldn't store them in plain text.
pretty sure this is crashing because the coordinates associated are nonsensical as the system either no longer exists or isn't intended to exist to the public and thus hides nothing relevant to the game.
then again, if i wanted (or had) to hide secret system names in the client i'd hash them with something like md5sum or better. I wouldn't store them in plain text.
pretty sure this is crashing because the coordinates associated are nonsensical as the system either no longer exists or isn't intended to exist to the public and thus hides nothing relevant to the game.
If you debug and dissassemble from the created dump, the break/crash happens in the code at:
Of course rax is the return register and contains 0x0 at this step, but some may find the term rax at this point very interesting so I posted it.
00007FF6A605D343 mov edx,dword ptr [rax+20h]Of course rax is the return register and contains 0x0 at this step, but some may find the term rax at this point very interesting so I posted it.
Its where the Invisible Pink Unicorn lives.
RAX is just the name of a register in assembly programming, one of the quick access cpu ram spots. EDX is also such a thing as well.If you debug and dissassemble from the created dump, the break/crash happens in the code at:
00007FF6A605D343 mov edx,dword ptr [rax+20h]
Of course rax is the return register and contains 0x0 at this step, but some may find the term rax at this point very interesting so I posted it.
P.S. I hate assembly programming
So from what I can gather, it's a fleet-carrier bug.
There are only 5 systems with Sabi
1) Sabi
2) Sabihilo
3) Sabik
4) Sabikami
5) Sabines
The 6th, 7th, 8th, (etc, etc) hit, are stations inside of systems.
There are plenty of Sabines stations which are searchable, and do not crash out the galaxy map.
But there is only 1 Sabiyhan and that's a fleet carrier registration K2V-7HW, owned by Commander Melting Cube (and at the time of searching) which is in the Teng Yeh system.
The Teng Yeh system is searchable and does not crash the game, as do the start ports inside the system like Brash Hub.
The galaxy map does not allow us to search for Fleet Carriers, but they are persistent entities in the galaxy, inside of a system map like a station, and ergo a part of the galaxy-map. Much like comets, they are both not in the game but also in the game.
I guess the carrier Sabiyhan didn't get the memo, and the games database tries to load in the (Entity)TYPE: STATION, to acquire the system id the station is in.
The game would then load in the sound for said system, (as every star type has its own sound in the game in the galaxy map).
but the Sabiyhan is of TYPE: FLEET_CARRIER which presumably has a different data structure that doesn't parser as Entity Type Station, so the game crashes.
It's equivalent to using the search term "Elysi"
which would find both the system Elysia and the fleet carrier Elysium.
In this case the galaxy map doesn't crash the game as the Carrier Elysium does not provide a "HIT" in the galaxy map search.
Or Tes for the system teshhub and the fleet carriers named Tesco.
You would have to grind through all the Tesla's though but again The Tesco fleet carriers do not give a "hit" in the galaxy map search.
For reasons unknown, "Sabiyhan" is an exception.
There are only 5 systems with Sabi
1) Sabi
2) Sabihilo
3) Sabik
4) Sabikami
5) Sabines
The 6th, 7th, 8th, (etc, etc) hit, are stations inside of systems.
There are plenty of Sabines stations which are searchable, and do not crash out the galaxy map.
But there is only 1 Sabiyhan and that's a fleet carrier registration K2V-7HW, owned by Commander Melting Cube (and at the time of searching) which is in the Teng Yeh system.
The Teng Yeh system is searchable and does not crash the game, as do the start ports inside the system like Brash Hub.
The galaxy map does not allow us to search for Fleet Carriers, but they are persistent entities in the galaxy, inside of a system map like a station, and ergo a part of the galaxy-map. Much like comets, they are both not in the game but also in the game.
I guess the carrier Sabiyhan didn't get the memo, and the games database tries to load in the (Entity)TYPE: STATION, to acquire the system id the station is in.
The game would then load in the sound for said system, (as every star type has its own sound in the game in the galaxy map).
but the Sabiyhan is of TYPE: FLEET_CARRIER which presumably has a different data structure that doesn't parser as Entity Type Station, so the game crashes.
It's equivalent to using the search term "Elysi"
which would find both the system Elysia and the fleet carrier Elysium.
In this case the galaxy map doesn't crash the game as the Carrier Elysium does not provide a "HIT" in the galaxy map search.
Or Tes for the system teshhub and the fleet carriers named Tesco.
You would have to grind through all the Tesla's though
but again The Tesco fleet carriers do not give a "hit" in the galaxy map search.For reasons unknown, "Sabiyhan" is an exception.
Last edited:
With my software testing head on, what would happen if the Fleet Carrier was renamed to something less controversial?
it's been a really long time since i've searched something by name in the game... but i thought fleet carrier names were eye candy like cmdr ship names. That the game only references your fleet carrier by the ship id and so only the carrier id would be searchable on the galaxy map since carrier names can be changed at will by owners... Searching by name would mean constant data syncs across all players whenever cmdr's decide to change their carrier name - which doesn't really make much sense for fdev to do. New carrier creation is a much less frequent action and easier to sync across players since it's a non-editable id.
The Fleet Carrier idea is very interesting and well thought out. The only issues I see there is that A: How the Term “Sabiyhan” first was found and B: Unless the fleet carrier owner is contacted for their maiming reasoning, I may suspect they named their carrier after hearing about it just to see what would happen if an FC had the name.
it would be a well thought out idea, if anyone bothered to see if you can even search for carriers thru the search field that causes this system crash (you can't. just tried). You can't even search for them by ship id.
Aye, that was indeed my thought, we can not search for carriers, the galaxy map search results in zooming to a system or station that meets the required text search.
but what if a carrier DID come up during a galaxy map search? Then that would not be an expected result for the developers nor the search code which parses the galaxy map search.
The could might not have even be updated, or NEED to be updated.
It shouldn't be an issue because the carriers are SUPPOSED to be flagged as unsearchable, right?
Therefore we can make a guess that the galaxy map search has no "catch{}" statement to handle unexpected results like what to do with faulty results that are not "station" or "system" so what we get instead is an unexpected datatype and an erroneous memory address which leads to a crash - aka a bug.
I'm a little way out of the bubble, but in order to support this theory, if I recall, when you search Sabiyhan the camera does starts to move before the crash, right?
If there is camera movement, we can use that to confirm the hypothesis that the search is erroneously honing in on the carrier location.
We fly to the location of the carrier which will be our origin [x,y,z], and perform the galaxymap search there.
The expected result would be the camera shouldn't move and the game crashes, correct?
Then one points the galaxymap camera towards 6 different locations about 100 light-years from out origin point so:
- 2 points along the x-axis,
- [x-stepSize, y, z]
- [x+stepSize, y ,z]
- 2 points along the y-axis
- [x, y-stepSize, z]
- [x, y+stepSize, z]
- 2 points along the z-axis
- [x, y, z-stepSize]
- [x, y, z+stepSize]
It wouldn't be definitive or conclusive, but it would add weight to the concept.
And this kiddies, is what it's like to make games, develop software or work in QA and testing.
This is how you spend most of your days work in the computing branch:
- 1% of the time coming up with a great idea.
- (We do that on the forums every day, "wouldn't it be cool if.....")
- 15% of the time just to making it work
- (which is your gut instinct of how long you "THINK" it's going to take you to make it).
- 20% of the time to make it work really well and enjoyable from feedback from friends and colleagues.
- 30% of the time making NOT work in unexpected ways (exploits/bugs)
- 30% integrating it with the main branch code so it doesn't break any other existing code.
- another 4%->999% of the time making NOT work in unexpected ways (exploits/bugs) from
- The code merger as new erroneous inputs can be gleaned from other peoples code
- After pushing the code to the live server environment where
- real-life networking issues,
- players and behavior
- and a multitude of players unique computer setups,
- Causing a slew of unexpected and impossible to foresee issues that need to be tracked back,
- patched,
- retested,
- pushed live again.
Last edited:
I'm sorry but are you high? The search box doesn't search carriers. There's no point in imagining an alternate reality where it did search carriers and that doing so is what causes the game to crash when talking about the game crashing in our reality ...where it's not searchable.
Carriers aren't the same unit type as stations, nor systems. In no possible imagination of how any of this code works would carrier names be looked at when querying a name. I'm pretty sure the client doesn't even ping Fdev servers when searching for names and that all of the hand-designed names are stored locally and all of the other names are procedurally generated and searched via the stellar forge (which is in your client and requires no communication to fdev to parse)