SetPlayerProximityFunction() bug

[John Adams]

Just found out that if you /camp in proximity of a spawn that utilizes the LUA function SetPlayerProximityFunction(), the server will crash when that player attempts to log back in. I cannot get the exact line that's crashing (debugs me to xtree) but this is a doosey. May be another reason my server has been crashing so much lately, as we've started using proximity on our spawns.
The fix is to move the player a safe distance from the NPC - which is not something I care to do manually.

[Arremis]

I would suggest to put in a preventive measure. If the player is trying to camp within a spawn proximity, the server should cancel the attempt to camp and give the player a warning: "Please move your character to a safer location before attempting to camp."

[John Adams]

I am not sure if there is a scenario on Live where players are told they cannot camp at a specific location. If there is, maybe that would be a good addition. But for this, LE will just fix the bug and we'll be ok with camping next to "aware" spawns.

[LethalEncounter]

Aye, I know what is causing it. I'll fix it tomorrow.

[John Adams]

Might have another bug with this. I am trying to spawn 2 of my custom NPCs that use the SetPlayerProximityFunction(), and the server is crashing when you enter the /spawn # command. Debugging it, I see something about playerproximity again:

Code: Select all

 	ntdll.dll!7c90100b() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]	
>	EQ2World.exe!Mutex::lock()  Line 116	C++
 	EQ2World.exe!ZoneServer::RemovePlayerProximity(Spawn * spawn=0x069afe30, bool all=false)  Line 2244	C++
 	EQ2World.exe!ZoneServer::AddPlayerProximity(Spawn * spawn=0x069afe30, float distance=20.000000, std::basic_string<char,std::char_traits<char>,std::allocator<char> > in_range_function="InRange", std::basic_string<char,std::char_traits<char>,std::allocator<char> > leaving_range_function="")  Line 2220	C++
 	EQ2World.exe!EQ2Emu_lua_SetPlayerProximityFunction(lua_State * state=0x06a25498)  Line 210	C++
 	EQ2World.exe!_luaD_precall()  + 0x19d bytes	C
 	EQ2World.exe!_luaV_execute()  + 0xad8 bytes	C
 	EQ2World.exe!_luaD_call()  + 0x43 bytes	C
 	EQ2World.exe!_lua_call()  + 0x65 bytes	C
 	EQ2World.exe!_luaD_rawrunprotected()  + 0x3a bytes	C
 	EQ2World.exe!_luaD_pcall()  + 0x3e bytes	C
 	EQ2World.exe!_lua_pcall()  + 0x53 bytes	C
 	EQ2World.exe!LuaInterface::CallSpawnScript(lua_State * state=0x06a25498, unsigned char num_parameters='')  Line 330 + 0x18 bytes	C++
 	EQ2World.exe!LuaInterface::RunSpawnScript(char * script_name=0x069d4598, char * function_name=0x00ae84d4, Spawn * npc=0x069afe30, Spawn * spawn=0x00000000, char * message=0x00000000)  Line 675 + 0x13 bytes	C++
 	EQ2World.exe!ZoneServer::CallSpawnScript(Spawn * npc=0x069afe30, unsigned char type=0, Spawn * spawn=0x00000000, char * message=0x00000000)  Line 936	C++
 	EQ2World.exe!Commands::Process(unsigned int index=1, EQ2_16BitString * command_parms=0x096ffba4, Client * client=0x06931028)  Line 1782	C++
 	EQ2World.exe!Client::HandlePacket(EQApplicationPacket * app=0x04e06c90)  Line 865	C++
 	EQ2World.exe!Client::Process(bool zone_process=true)  Line 1164 + 0xc bytes	C++
 	EQ2World.exe!ZoneServer::ClientProcess()  Line 1052 + 0xa bytes	C++
 	EQ2World.exe!ZoneServer::Process()  Line 627	C++
 	EQ2World.exe!ZoneLoop(void * tmp=0x0692a868)  Line 2374 + 0x8 bytes	C++
 	EQ2World.exe!_callthreadstart()  Line 293 + 0xf bytes	C
 	EQ2World.exe!_threadstart(void * ptd=0x0692b590)  Line 277	C
 	kernel32.dll!7c80b713() 	

Using /spawn with other spawns that do NOT use the SetPlayerProximityFunction seem to spawn ok.

[LethalEncounter]

What is the crash error? That looks just like what I told you earlier - that the lock was timing out and it wasn't an error. Before you submit another one of these that is caused by the lock could you please post the value you used in your registry for the lock timeout? I'm almost positive that is the problem.

[John Adams]

Er... The error is the same one as before, about the memory at address xxxooo cannot be "written". or "read", depending on what mood the machine is in, I guess. I do not get any other error messages.
The value for my CriticalSectionTimeout is back to 0x00278d00.
Look, if you'd rather me not waste my time reporting these, I won't. My server crashes even when people are not on it, it's just sitting with 0 zones and 0 clients, and the system *beeps* and I look at it, and the server has crashed.
I suppose next thing it'll be my hardware that is malfunctioning. So I will move the server off to a VM again for a few days to test that theory. If no crashes, then it's my hardware freaking out (it is a few years old, running 24x7, so it is possible).
Let it slide, I guess... since these reports are useless. I'll try another machine for a while and let you know.

[LethalEncounter]

I wasn't saying it was useless, especially since your other ones have lead to some of the crash bug fixes. I was just skeptical that the crash was actually a crash since the last few have been relating to the locking, something that cannot (AFAIK) crash. And since I didn't hear back from you regarding your value of the timeout I assumed that your value was still just too low. What was your value before you changed it back to the original one? Did you reboot after changing it? Hot trying to be condescending, just trying to get all the information so I can possibly fix whatever is causing the problems.

[John Adams]

Yeah I have rebooted since the change, and it previously was set to 30 which is what I think you recommended. There is a little more history with that machine, which is after installing MSSQL 2005 one day suddenly there was this debugger prompt everytime something happened to the emulator which never happened before installing MSSQL + it's VS 2005 environment (I guess for writing some Business Intelligence blah whatever that I didn't ask it to install heh).
The end result was me frantically trying to remove VS2005 and the JIT/Debugger catchers so the server would simply crash and restart like it used to before that install. Don't get me wrong, EQ2Emu was crashing a lot before, too but we got used to that being related to actions we were taking in game like reload and repop. Now, as I said, I could sit here watching the console and without anything at all changing on the screen (no zones, no players), crash - memory cannit be "read".
The good news: maybe I have been running since yesterdays post on the original VM I set up for EQ2Emulator and not had one crash yet. I'll leave it there for a week, see if I can catch anything happening - but this really may come down to my machine afterall... which will now require a complete OS reload, since I cannot seem to get rid of those debug or error reporting dialogs.
I am now very disappointed with whatever tendrils VS2005 puts in a machine, that it does not remove when uninstalling. Sigh.

[LethalEncounter]

heh glad to hear that it might be the machine instead of the code. Not because it is less work for me, but because... OK maybe because it means less work for me Gotta love Microsoft.

[John Adams]

Ok, I have completely twisted my analysis and explanation of this problem lol... first off, if you see a call stack posted, it is from my WinXP station and my dev server (usually), or my live server running debug to see if I can catch the bad guys. When you hear my whining and bitching about memory cannot be "written" or "read", that is coming from the physical server that normally runs the EQ2World.exe for my live server.
The above mentioned crash is reproducable 100% of the time on either of my servers in any mode - so whenever you got the time, either load the TessEQ2 DB and SpawnScripts, then /spawn 6, which is an NPC that has a SetPlayerProximityFunction() in it's function Spawn(), or likely just create a spawn w/script with the proximity set and try and /spawn it. I am ruling out my hardware on this (one crash type) only because it happens on 3 different machines now.
TessEQ2 has been running on the VM for 24+ hours without a single crash, so I will remedy my hardware problem eventually. For now, she's running on the VM - and again, I have reproduced this world crash by summoning a spawn that has a SetPlayerProximityFunction() in it's function Spawn().
I'm not makin this up. It really crashes. And I have no explanation why my call stacks look the way they do when debugging it.