PF_VarString crash bug (and fix)

[mh]

[Spike]

[mh]

No issues with any of that.

It's actually the original ID1 progs.dat, and I've observed it crashing on straight ports of the original code (both Win and GL) to MSVC 2008, as well as on ports of modded engines. Odd, huh?

Obviously a deeper VM bug is at work here, but like I said, it's not a rigourous fix. Just a "swallow the error and let the engine keep running" thing.

The problem is that pr_globals (which is float *) gets a NaN in it, which then messes with G_STRING (pr_strings + *(string_t *)&pr_globals[o]), causing havoc in PF_VarString by translating to a negative array index for pr_strings[]. I haven't bothered investigating further for the simple reason that my fix is "good enough for now".

[Spike]

[r00k]

[mh]

[Spike]

as I said earlier:
*(float*)&host_client->edict->v.netname -1.#QNAN00 float

player names are stored within the heap, allocated at init time, the pointer used to reference them is svs.clients which persists through all map changes.
The progs is always loaded after the initial heap, in an area which is always cleared out. There is no map info between the clients list and the progs string table.
This means that (svs.clients[foo].name - pr_strings) will always come out as a negative value, and one which is fairly small, typically less than -8mb. The bit pattern of a negative number has the highest bits all set to 1, which is the same pattern as a negative nan (highest 9 bits are 1).
On every map change, you get a bprint(self.netname);bprint(" exited the level\n"); and self.netname is a value between -8m and -1 and is thus always going to be detected as a negative nan.
But it is required behaviour - that particular nan is perfectly safe.

[mankrip]

I've implemented mh's fix from the first post, but as Spike said, the obituary messages stopped displaying the player name, so I disabled the fix.

[Baker]

[andrewj]

The "fix" in this tutorial has been shown to be bogus, and hence this thread should be renamed and moved out of the tutorials section.

[mh]

I think "bogus" is too strong a word to use here.

It's still possible to reproduce the bug with certain build configurations, and from unmodified source-as-released, so something is wrong somewhere. My initial analysis of cause and solution has definitely been shown to be premature and flawed, no contest there, so retention of the thread with the addition of a "don't actually do this" warning (which purpose I guess this post serves) is probably a good idea - at the very least if further analysis throws up the real cause and solution it can be added at a future date and be of benefit to the community.