Trashed sentinel, AKA trahshed sentinal

[qbism]

Once again, I dip my clouded mind into this font of enlightenment that is I3D... has anyone wrestled with trashed sentinel problems?

I'm getting a strange error. A few specific 'big maps' with extended limits give me "trashed sentinel" system error on respawn. Initial map load and save game load are fine, it's only respawn. If I comment-out Hunk_Check, it appears that the map is trying to load twice per the console, then errors with "signon reply is 1, already at 1".

An example is arcanum4, which uses Drake. It always errors out on respawn in qbismSuper8. But it works fine in Fitzquake, so it's not the map or mod.

[mh]

You've most likely overrun a buffer somewhere. You can easily mod Hunk_Check to tell you the allocation name prior to the trashed sentinal, which stands a good chance of being the one that you overran:

Code: Select all

void Hunk_Check (void)
{
   hunk_t   *h;
   hunk_t   *hprev = NULL;

   for (h = (hunk_t *)hunk_base ; (byte *)h != hunk_base + hunk_low_used ; )
   {
      if (h->sentinal != HUNK_SENTINAL)
         Sys_Error ("Hunk_Check: trahsed sentinal after %s", hprev ? hprev->name : "hunk base");
      if (h->size < 16 || h->size + (byte *)h - hunk_base > hunk_size)
         Sys_Error ("Hunk_Check: bad size after %s", hprev ? hprev->name : "hunk base");

      hprev = h;
      h = (hunk_t *)((byte *)h+h->size);
   }
}

Find the Hunk_AllocName call that used that name, find the pointer it returned, and you can trace from there.

[qbism]

Thanks, that is much more elegant than manually passing the calling function or names.

"modedges" is the previous name. So far haven't seen the cause of overrun. Since the issue only occurs on map reload, will be looking for connection between respawn and edges.

[qbism]

Digging deeper into this, the server sends a serverinfo packet upon respawn. Then it sends a SECOND serverinfo packet after receiving signon = 1. That's a no-no. And this happens ONLY upon player respawn and ONLY on arcanum4 (and occasionally on one or two others).

Looking at other big map engines, BJP Winquake doesn't have this bug. Neither does Fitzquake as mentioned above.

In CL_ParseServerInfo, I added a check which will at least prevent trashed sentinels and crash-

Code: Select all

 if (cls.signon > 0)
     Host_Error("Repeat serverinfo packet at signon %i", cls.signon);


Doing a search came up with this DP log entry from 2003 (googl skilz ) :
got rid of my attempts to delay sending the ServerInfo packet until the first message from the client, because the ServerInfo packet is already handled by the quake reliable message system and thus will be re-sent multiple times... back to the drawing board on my attempts to fix quake through NAT routers

Not sure if it's a clue, because I'm running single player on localhost.

[Spike]

is it the server or the client that's messing up, or both?
try connectivity with other engines that do support those maps.

[qbism]

It seems to be the server's fault, unless there's a means for a client to request a serverinfo message AFTER signon. Possibly the client is sending a corrupted message, in very rare circumstances, that by chance includes signon = 0.

Next step will be some checks on the server side for singons out of sequence. If server receives 0 , then 1, then 0 again, something is wrong.

EDIT: The issue occurs when SV_ConnectClient calls SV_SendServerinfo, and SV_SpawnServer calls it again. The details of this circumstance are still elusive. And I haven't found the particular feature of bjp Winquake that prevents it. But I will add this sanity check at the top of SV_SendServerinfo and roll on:

Code: Select all

    if (client->sendsignon == true)  //qbism - don't send serverinfo twice.
    {
        Con_DPrintf ("Warning, attempted to send duplicate serverinfo.\n");
        return;
    }