SWDS.dll Crashes.

[Pierre-Marie Baty]

oh ok...

the CBaseStuff is always located behind the edict_s pvPrivateData pointer, right ?

struct edict_s
{
   qboolean free;
   int serialnumber;
   link_t area; // linked to a division node or leaf
 
   int headnode; // -1 to use normal leaf check
   int num_leafs;
   short leafnums[MAX_ENT_LEAFS];
   float freetime; // sv.time when the object was freed
   void* pvPrivateData; // Alloced and freed by engine, used by DLLs
   entvars_t v; // C exported fields from progs
 
   // other fields from progs come immediately after
};

well wouldn't it be possible that you do it yourself (i.e malloc() some space behind this pointer and zero it out), not forgetting to free it when you set the FL_KILLME flag ?

That would be wasted space, but could probably prevent it to crash.

If you know the address of the entvars struct for that entity, you can safely deduce the address of its pvPrivateData pointer too ( -4 ). I'd investigate there...

Problem with doing that is the mod might try to access it and think its cbaseentity, when its not.

[Cheeseh]

Im just guessing now..

hmm,
did you set "free" to 1 (in edict_s of entity) ? Does that make it think that its not a valid entity and can be overwritten when making new entities?

Originally Posted by Cheeseh

Im just guessing now..

hmm,
did you set "free" to 1 (in edict_s of entity) ? Does that make it think that its not a valid entity and can be overwritten when making new entities?

The ents are removed by the engine so I'm assuming that it handles all that (look in the sdk, I never seen free being set anywhere).

[Pierre-Marie Baty]

Originally Posted by voogru

Problem with doing that is the mod might try to access it and think its cbaseentity, when its not.

That's precisely my point. The point is of course not to build a fully featured instance of CBaseEntity by hand, but not to let the mod land on an unitialized pointer. If all the mod does is just checking/setting two or three CBaseEntity member values in this area, it'll read zeroes and set random stuff (which we don't care so far), but at least it won't produce an access violation error, which might be sufficient to prevent it to crash.

Once this runs you can then trace manually to figure out what the mod reads and writes there and you'll understand why it needs this CBaseEntity pointer. You will then be able to provide it with better failsafe mechanisms.

Originally Posted by Pierre-Marie Baty

That's precisely my point. The point is of course not to build a fully featured instance of CBaseEntity by hand, but not to let the mod land on an unitialized pointer. If all the mod does is just checking/setting two or three CBaseEntity member values in this area, it'll read zeroes and set random stuff (which we don't care so far), but at least it won't produce an access violation error, which might be sufficient to prevent it to crash.

Once this runs you can then trace manually to figure out what the mod reads and writes there and you'll understand why it needs this CBaseEntity pointer. You will then be able to provide it with better failsafe mechanisms.

FYI, With using the create_named_entity function, a CBaseEntity instance is provided (just real basic). Which is currently what I'm doing to prevent the crashes with the mod freaking out, just these swds.dll crashes acting up.

I'm thinking it just might be something with the specific entity (which I have others that dont seem to crash and are used a fair amount of times). So I'm gonna look into that.

[sfx1999]

I bet it's something stupid like this:

CEBaseEntity *newhive = new CHive
 newhive = 52
 blah = *newhive

That's my guess.